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Foreword 


The Fibre Channel provides a transport vehicle 
for the upper layer Intelligent Peripheral Inter- 
face (IPI) and Small Computer System Interface 
(SCSI) command sets, and the High-Performance 
Parallel Interface (HIPPI) data framing. The 
Fibre Channel is capable of replacing the SCSI, 
IPI and HIPPI physical interfaces with a protocol- 
efficient alternative that provides performance 
improvements in distance and/or speed. 


IP] commands, SCSI commands, and HIPPI data 
framing operations may all be intermixed on the 
Fibre Channel. Proprietary and other command 
sets may also use and share the Fibre Channel, 
but such use is not defined. 


The Fibre Channel is optimized for predictable 
transfers of large blocks of data such as used for 
file transfers between’ processors’ (super, 
mainframe, super-mini, etc.) storage systems 
(disk and tape), communications, and to output 
only devices such as laser printers and raster 
scan graphics terminals. 


The Fibre Channel 
levels as follows: 


standard is organized in 


- FC-0 defines the physical portions of the Fibre 
Channel including the fibre, connectors, and 
optical parameters for a variety of industy sup- 
ported data rates and physical media. A serial 
coax version may also be defined for limited dis- 
tance applications. 


FC-O level provides the point-to-point physical 
portion of the Fibre Channel. Signaling rates 
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from 132.813 MBaud, 265.625 Mbaud, 
531.25MBaud, 1.0625Gbaud are specified. These 
signaling rates correspond to data transfer rates 
of 12.5 MBytes/s (100 Mbits/s), of 25 MBytes/s 
(200 Mbits/s), of 50 MBytes/s (400 Mbits/s), and 
of 100 MBytes/s (800 Mbits/s). 


- FC-1 defines the transmission protocol, which 
includes the serial encoding, decoding, and the 
error control. 


- FC-2 defines the signaling protocol which 
includes the frame structure and_ byte 
sequences. 


- FC-3 defines the common service interface to 
FC-4 


- FC-4 is the highest layer in the Fibre Channel 
standards set. It defines the channel protocol, or 
mapping, between the lower layer FC standards 
and the IPI and SCSI command sets, and the 
HIPP! data framing. 


- FC-F describes the requirements placed on 
Fabrics which intend to support the Fibre 
Channel. 


The Fibre Channel protocol is simple in order to 
minimize implementation cost and enhance 
throughput. The transmission medium is iso- 
lated from the control protocol so that implemen- 
tation of point-to-point links, multi-drop bus, 
rings, crosspoint switches, or other special 
requirements may be made in a technology best 
suited to the environment of use. 
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Fibre Channel - Physical (FC-PH) 


1 Scope 


This standard provides the physical layer of a 
high performance serial link for support of the 


2 Normative references 


The following standards contain provisions 
which, through reference in FC-PH, constitute 
provisions of this standard. At the time of publi- 
cation, the editions indicated were valid. All 
standards are subject to revision, and parties to 
agreements based on this standard are encour- 
aged to investigate the possibility of applying the 
most recent editions of the standards listed 
below. Members of IEC and ISO maintain regis- 
ters of currently valid International Standards, 
and ANSI for American National Standards. 


Fiber Distributed Data Interface Media Access 
Control - X3T9/84-100 X3T9.5/83-16 REV-10 


All FOTPs are EIA/TIA-455-XXX and all OFSTPs 
are EIA/TIA-526-XXX.* 


FOTP-30 - Frequency Domain Measurement of 
Multimode Optical Fiber Information Trans- 
mission Capacity 


FOTP-45 - Microscopic Method for Measuring 
Fiber Geometry of Optical Waveguide 
Fibers 


higher layer protocols associated with HIPPI, IPI, 
SCSI and others. 


FOTP-48 - Measurement of 
Cladding Diameter 
Instruments 


Optical Fiber 
Using Laser-Based 


FOTP-51- Pulse Distortion Measurement of 
Multimode Glass Optical Fiber Information 
transmission Capacity 


FOTP-54 - Mode Scrambler Requirements for 
Overfilled Launching Conditions to Multi- 
mode Fibers 


FOTP-107 - Return Loss for Fiber Optic Compo- 
nents 


FOTP-127 - Spectral Characteristics of Multimode 
Lasers. 


FOTP-168 - Chromatic Dispersion Measurement 
of Multimode Graded-Index and Single- 
Mode Optical Fibers by Spectral Group 
Delay Measurement in the time Domain. 


FOTP-171 - Attenuation by Substitution Measure- 
ment for short length Multimode Graded- 
Index and Singlemode Optical Fiber Cable 
Assemblies. 


Fiber Optic Test Procedure (FOTP) and Fiber Optics Systems Test Procedure (OFSTP) standards are developed and 
published by the Electronics Industries Association under the EIA-RS-455 and the EIA-RS-526 series of standards. 


Copies may be obtained by writing to: 


DIRECTOR OF TECHNICAL PROGRAMS 

Information & Telecommunication Technologies 
ELECTRONIC INDUSTRIES ASSOCIATION 

2001 Eye Street, N.W. 

Washington, D.C. 20006 
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FOTP-176 - Measurement Method of Optical 
Fiber Geometry by Automated Grey-Scale 
Analysis 


FOTP-177 - Numerical Aperture Measurement of 
Graded-Index Optical Fibers 


EIA/TIA-492AAAA - Detailed Specification for 
62.5 pm Core Diameter/125 wm Cladding 
Diameter Class 1a Multimode, Graded 
Index Optical Waveguide Fibers. 


3 Definitions and conventions 


3.1 Definitions 


For the purposes of this standard, the following 
definitions and figure 10 through figure 14 apply. 


3.1.1 alias: an optional, alternate address identi- 
fier recognized by an N Port in addition to 
its native address identifier. 


3.1.2 attenuation: the Optical 
expressed in units of dB. 


power loss 


3.1.3 average power: the optical power measured 
using an average reading power meter 
when the Fibre Channel is transmitting 
continuous valid symbols. 


3.1.4 baud: the coded bit rate per second. 


3.1.5 beginning running disparity: the Running 
Disparity present at a Transmitter when 
Encoding of the Special Code associated 
with an Ordered Set is initiated, or at a 
Receiver when Decoding of the Special 
Character associated with an Ordered Set 
is initiated. 

3.1.6 broadcast: TBD 


3.1.7 buffer: a logical construct which holds the 
Data Field contents of a single frame i.e. 
Data Field size < a buffer. 


3.1.8 byte: an eight-bit entity with its least signif- 
icant bit denoted as bit 0 and most signif- 
icant bit as bit 7. 


3.1.9 cable plant: the cable plant consists of all 
the optical elements, for example fiber, 
connectors, splices, etc. between a trans- 
mitter and a receiver. 


EIA/TIA-492BAAA - Detail Specification for Class 
I\Va___ Dispersion-Unshifted | Single-Mode 
Optical Waveguide Fibers Used in Commu- 
nications Systems | 


OFSTP-2- Effective Transmitter Output Power 
Coupled Into Singlemode Fiber Optic Cable 


OFSTP-3- Fiber Optic Terminal 
Receiver Sensitivity and 
Receiver Input 


Equipment 
Maximum 


OFSTP-14 - Optical Power Loss Measurement of 
Installed Multimode Fiber Cable Plant 


3.1.10 center wavelength (laser): the nominal 
value central operating wavelength. It is 
the wavelength, defined by a peak mode 
measurement (See FOTP-127) where the 
effective optical power resides. 


3.1.11 center wavelength (LED): the average of 
the two wavelengths measured at the half 
amplitude points of the power spectrum. 


3.1.12 character: any transmission character 
associated by the FC-1 transmission code 
with a FC-2 data byte or special code. 
Transmission characters are generated 
and interpreted only by FC-1. 


3.1.13 circuit: a bidirectional path within the 
Fabric for the flow of electric signals. 


3.1.14 code bit: the smallest time period used by 
the FC-0O for transmission on the media. 


3.1.15 code violation: an error condition that 
occurs when a received’ Transmission 
Character cannot be decoded to a Valid 
Data Byte or Special Code using the 
validity checking rules specified by the 
Transmission Code. 


3.1.16 comma: the seven bit sequence 0011111 
or 1100000 when appearing in an encoded 
stream. 


3.1.17 comma character: 
containing a comma. 


a Special Character 


3.1.18 concatenation: a logical operation that 
“joins together” strings of data and is 
represented with a symbol ”||”. In FC-2, two 
or more fields are concatenated to provide 
a reference of uniqueness. (e.g., S_ID||X_ID) 


3.1.19 Connection: see Dedicated Connection. 


3.1.20 Connectionless service: communication 
between two N_ Ports performed without a 
Dedicated Connection. 


3.1.21 Connection Initiator: the source N_ Port 
which initiates a Class 1 Connection with a 
destination N Port through a Connection 
request and also receives a valid response 
from the destination N_ Port to complete the 
Connection establishment. 


3.1.22 Connection Recipient: the destination 
N Port which receives a Class 1 Con- 
nection request from the Connection Initi- 
ator and accepts establishment of the 
Connection by transmitting a valid 
response. 


3.1.23 Credit: the maximum number of receive 
buffers allocated to a transmitting N Port 
or F_Port. It represents the maximum 
number of outstanding frames which can 
be transmitted by that N Port without 
causing buffer overrun at the receiver. 


3.1.24 current running disparity: the Running 
Disparity present at a Transmitter when 
Encoding of a Valid Data Byte or Special 
Code is initiated, or at a Receiver when 
Decoding of a Transmission Character is 
initiated. 


3.1.25 data byte: a string of eight bits passed to 
and from the FC-2 layer as a unit. (See 


data character and transmission. char-. 


acter.) 


3.1.26 data character: any Transmission Char- 
acter associated by the Transmission Code 
with a Valid Data Byte. 


3.1.27 decoding: validity checking of received 
Transmission Characters and generation of 
Valid Data Bytes and Special Codes from 
those characters. 


3.1.28 Dedicated Connection: a communicating 
route/circuit guaranteed and retained by 
the Fabric for two given N_Ports. 


3.1.29 destination N_Port: the N_ Port identified by 
the Destination Identifier (D_ID) to which 
the frame is transmitted. 


3.1.30 disconnection: the process of removing a 
Dedicated Connection between two 
N_ Ports. | 


FC-PH REV 2.1, May 25, 1991 


3.1.31 disparity: the difference between the 
number of ones and zeros in a Trans- 
mission Character. 


3.1.32 dispersion TBD. 
3.1.33 EIA: Electronic Industry Association 


3.1.34 encoding: generation of valid Trans- 
mission Characters from Valid Data Bytes 
and Special Codes. 


3.1.35 Exchange: the basic mechanism to 
transfer information consisting of one or 
more related non-concurrent Sequences 
which may flow in the same or opposite 
directions. An Exchange may span a set of 
related N Ports with a common control 
structure. An Exchange may span across 
Class 1 disconnects. The Exchange is 
uniquely identified by an Originator 
Exchange _ldentifier | (OX_ID) and a 
Responder Exchange Identifier (RX_ID). 


3.1.36 Exchange Identifier (X_ID): a generic ref- 
erence to OX_ID and RX_ID. 


3.1.37 Exchange_Status_Block: a logical con- 
struct which contains the state of an 
Exchange. An Originator N Port has an 
Originator Exchange Status Block and the 
Responder N Port has a Responder 
Exchange Status Block for each concur- 
rently active Exchange. 


3.1.38 extinction ratio: the ratio of the low, or off 
optical power level, (P,)to the high, or on 
optical power level, (P.,) when the station is 
transmitting a stream of symbols. 
Extinction Ratio (%) = (P,/P,,)*100 


3.1.39 eye opening: the portion of the bit time 
which is error free to a given bit error rate 
(BER <10-'2 for Fiber Channel). 


3.1.40 F_Port: the link_Control_ Facility within the 
Fabric which attaches to an N_Port through 
a link. An F_Port is not FC-2 addressable. 


3.1.41 Fabric: an entity which can interconnect 


any two N_Ports attached to it and can be 
completely navigated by the D_ID con- 
tained in the FC-2 frame header. 


3.1.42 Fabric Entry/Exit Point: the F_Port which 
directly attaches to an N Port through a 
link. 


3.1.43 fibre: the transmission media specified in 
FC-0, including glass, plastic, and copper. 


3.1.44 fibre optic cable A jacketed optical fibre(s). 


| 
| 
| 
| 
| 
| 
| 
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3.1.45 fibre optic test procedure: (FOTP) - Stand- 


ards developed and published by the Elec- 
tronic Industries Association (EIA) under 
the EIA-RS-455 series of standards. 


3.1.46 frame: an indivisible unit of information 
demarcated by unique character strings 
called delimiters. 


3.1.47 Frame Content: the information contained 
in a frame between its SOF and EOF delim- 
iters, excluding the delimiters. 


3.1.48 Hunt Group: a set of N Ports with a 
common alias address identifier managed 
by a single common controlling entity. 


3.1.49 Idle Sequence: a stream of Idle Words 
transmitted during periods of N_ Port inac- 
tivity and as a spacing mechanism 
between frames. 


3.1.50 Idle Word (Idle): an ordered set of four 
transmission characters as defined in FC-1 
denoting a word boundary. The Idle Word 
is also referred to as an Idle. 


3.1.51 ignored: 
receiver. 


a field that is interpreted by the 


3.1.52 information transfer: information trans- 
ferred which may be data, commands, or 
responses. 


3.1.53 initialization: the period beginning with 
power on of an FC-1 level and continuing 
until the Transmitter and Receiver of that 
level become Operational. | 


3.1.54 Intermix: a service which interleaves 
Class 2 and Class 3 frames on an estab- 
lished Class 1 Connection. 


3.1.55 InBand address: the address of the desti- 
nation N Port embedded within the trans- 
mitted frame itself, as part of the frame 
structure. 


3.1.56 jitter: deviations from the ideal timing of 
an event which occur at high frequencies. 
For deviations at low frequencies and addi- 
tional information see wander. Jitter is cus- 
tomarily subdivided into deterministic and 
random components. 


3.1.57 jitter, deterministic (DJ): timing distortions 
caused by normal circuit effects in the 
transmission system. Deterministic jitter is 
often subdivided into duty cycle distortion 
(DCD) caused by propagation differences 
between the two transitions of a signal and 
data dependant jitter (DDJ) caused by the 


interaction of the limited bandwidth of the 
transmission system components and the 
symbol sequence. 


3.1.58 jitter, random (RJ): jitter due to thermal 
noise which may be modeled as a 
Gaussian process. The peak-to-peak value 
of RJ is of a probabilistic nature and thus 
any specific value requires an associated 
probability. 


3.1.59 level: a document artifice used to group 
related architectural functions. No specific 
implementation is intended between levels 
and actual implementations. 


3.1.60 link: two unidirectional fibres transmitting 
in opposite directions. 


3.1.61 Link_Control_Facility: a link hardware 
facility which attaches to the end of a link 
and manages transmission and reception 
of data. It is contained within each N_Port 
and F_Port and includes the link trans- 
mitter and receiver mechanism. 


3.1.62 loopback: a mode of FC-1 operation in 
which information- passed to the FC-1 
Transmitter for transmission is shunted 
directly to the FC-1 Receiver, overriding 
any signal detected by the Receiver on its 
attached Fibre. | 


3.1.63 mandatory: a function which is supported 
by all compliant implementations. 


3.1.64 mean launched power: the average power 
for a continuous valid symbol sequence 
coupled into a fibre at point S as shown in 
8. 


3.1.65 media interface connector: a fibre con- 
nector which connects the fibre media to 
the Fibre Channel attachment. The MIC 
consists of two halves. The MIC plug is the 
male half used to terminate an optical fibre 
signal transmission cable. The MIC recep- 
tacle is the female half which is associated 
with the Fibre Channel station. 


3.1.66 MIC receptacle: the fixed or stationary 
female half of the MIC which is part of the 
transmitter and/or receiver in a_ Fibre 
Channel station. 


3.1.67 MIC plug: the male half of the MIC which 
terminates an optical signal transmission 
cable. 


3.1.68 multicast: TBD 


3.1.69 Native address identifier: the address iden- 
tifier required by each N Port which is 
unique within the address domain of the 
Fabric. 


3.1.70 Node: a collection of one or more N_ Ports 
controlled by a level above FC-2. 


3.1.71 N_Port: a hardware entity at the Node end 
of the link which includes a 
link_Control_ Facility. An N Port is 
assigned a system unique identifier called 
N_ Port Identifier and is addressed by this 
Identifier. It may act as an Originator, a 
Responder, or both. 


3.1.72 non-repeating ordered set: an Ordered 
set which, when issued by FC-2 to FC-1 for 
transmission, is to be transmitted once. 


3.1.73 Not Operational: a Receiver or Trans- 
mitter that is not capable of receiving or 
transmitting an encoded bit = stream, 
respectively, based on the rules defined by 
this standard for error control. The FC-1 
level is Not Operational during Initializa- 
tion. A Receiver or Transmitter that 
becomes Not Operational after Initialization 
is complete requires external intervention 
(e.g., reset, repair) before it can become 
Operational. (The FC-1 level is Not Opera- 
tional during Initialization.) 


3.1.74 numerical aperture: the sine of the radi- 
ation or acceptance half angle of an optical 
fibre, multiplied by the refractive index of 
the material in contact with the exit or 
entrance face. See FOTP-177. 


3.1.75 open fibre control (OFC): a safety interlock 
system that controls the optical power level 
on an open fibre cable. 


3.1.76 operation: a group of one or more related 
Exchanges. An operation is a higher level 
construct bounded by an 
Operation Identifier (O_!D). 


3.1.77 operational: a Receiver or Transmitter 
that is capable of receiving or transmitting 
an encoded bit stream, respectively, based 
on the rules defined by this standard for 
error control. Those Receivers capable of 
accepting signals from Transmitters 
requiring laser safety procedures are not 
considered Operational after power on until 
a signal of a duration longer than that 
associated with laser safety procedures is 
present at the Fibre attached to the 
Receiver. 
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3.1.78 Operation Initiator: The source N_ Port (or 
Node) which initiates an Operation with a 
destination N Port (or Node) and assigns 
an Operation Identifier through the first 
Exchange of the Operation. 


3.1.79 Operation Recipient: the destination 
N Port (or Node) which receives the Oper- 
ation initiation from the Operation Initiator 
and participates in the Operation so initi- 
ated. 


3.1.80 optical fall time: the time interval for the 
falling edge of an optical pulse to transition 
from its 90% amplitude level to its 10% of 
amplitude level. 


3.1.81 optical fibre: dielectric material that guides 
light; optical waveguide. 


3.1.82 optical path power penalty: the additional 
loss budget required to account for degr- 
adations due to reflections and the com- 
bined effects of dispersion resulting from 
intersymbol interference, mode-partition 
noise, and laser chirp. 


3.1.83 optical return loss (ORL): the ratio 
(expressed in units of dB) of optical power 
reflected by a component or an assembly 
to the optical power incident on a compo- 
nent port when that component. or 
assembly is introduced into a link or 
system. (See FOTP-107). 


3.1.84 optical rise time: the time interval for the 
rising edge of an optical pulse to transition 
from its 10% of amplitude levels to its 90% 
of amplitude level as specified. 


3.1.85 optical reference plane: the plane that 
defines the optical boundary between the 
MIC plug and the MIC receptacle. 


3.1.86 optional: features that are not required by 
the standard. However, if any optional 
feature defined by the standard is imple- 
mented, it will be implemented according 
to the standard. 


3.1.87 ordered set: a Transmission Word con- 
taining a K28.5 Special Character in its first 
(leftmost) position and designated to have 
special meaning (e.g., frame delimiters and 


Idle Words). 
3.1.88 Originator: the logical function in an 
N Port responsible for _ initiating an 


Exchange. An Originator may be a master 


| 
| 
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or slave (IPI), initiating controller or target 
controller (SCSI), or source (HIPPI). 


3.1.89 Payload: contents of Data Field of a frame, 
excluding Optional Header(s), if present. 
(see 34) 


3.1.90 physical link: the full-duplex physical layer 
association between adjacent FC-1 entitles 
(in. nodes or paths) in a Fibre Channel 
Path, i.e., a pair of Physical links. 


3.1.91 PMD: physical media dependent as 
defined by ANSI X3T9.5 document. 


3.1.92 power on: a Power on state has occurred 
when the power supply voltages are within 
their normal operating tolerances. At this 
point any circuits or optical devices may be 
assumed to be in a fully operational state. 


3.1.93 receiver: the portion of a link Control 
Facility dedicated to receiving an encoded 
bit stream from a Fibre, converting this bit 
stream into Transmission Characters, and 
Decoding these characters using the rules 
specified by this standard. 


3.1.94 receiver (RX): an optoelectronic circuit that 
converts an optical signal to an electrical 
retimed serial logic signal. 


3.1.95 receiver sensitivity: defined as the 
minimum acceptable value of average 
received power at point R to achieve a 
10-12 BER. It takes into account power pen- 
alties caused by use of a transmitter with 
worst-case values of extinction ratio, jitter, 
pulse rise and fall times, optical return loss 
at point S, receiver connector degradations 
and measurement tolerances. The 
receiver sensitivity does not include power 
penalties associated with dispersion, jitter, 
or reflections from the optical path; these 
effects are specified separately in the allo- 
cation of maximum optical path penalty. 
Sensitivity takes into account worst-case 
operating and end-of-life (EOL) conditions. 


3.1.96 receiver overload : the maximum accept- 
able value of the received average power 
at point R for a 10-!2 BER. 


3.1.97 reflections: caused by refractive index dis- 
continuities along the optical path. 


3.1.98 repeating ordered set: an Ordered Set 
which, when issued by FC-2 to FC-1 for 
transmission, is to be repetitively trans- 


mitted until a subsequent transmission 
request is issued by FC-2. 


3.1.99 return loss: see optical return loss. 


3.1.100 relative intensity noise (RIN): laser noise 
where the noise is measured relative to the 
average optical power. Units are typically 
either 1/Hz or dB/Hz. 


3.1.101 reflection induced intensity noise (RIIN): 
a form of RIN caused by optical feedback 
into a source. 


3.1.102 reserved: a field which is filled with 
binary zero(s) by the Source and is not 
interpreted by the Destination. Each bit in 
the reserved field is denoted by ’r’. 


3.1.103 Responder: the logical function in an 
N Port responsible for supporting the 
Exchange initiated by the Originator in 
another N Port. A Responder may be a 
master or slave (IPI), initiating controller or 
target controller (SCSI), or the destination 
(HIPPI). 


3.1.104 running disparity: a binary parameter 
indicating the cumulative Disparity (positive 
or negative) of all previously issued Trans- 
mission Characters. Running Disparity is 
one of the inputs used to determine the 
proper Transmission Character to generate 
during Encoding and to check Transmission 
Character validity during Decoding. 


3.1.105 Sequence: a set of one or more related 
Data frame(s), with a = common 
Sequence _ID (SEQ ID), transmitted 
unidirectionally from one N_ Port to another 
N Port with corresponding link _Control 
frame, if any, transmitted in response to 
each Data frame. 


3.1.106 Sequence Initiator: the source N_ Port 
which initiates the Sequence and transmits 
Data frame(s) to the destination N_ Port. 


3.1.107 Sequence Recipient: the destination 
N Port which receives Data_Frames from 
the Sequence Initiator and, if applicable, 
transmits (link_Control) responses to the 
Sequence Initiator, unless suppressed. 


3.1.108 Sequence Status Block: a logical con- 
struct and preferably a hardware facility 
which tracks the state of a Sequence. Both 
the Sequence Initiator and the Sequence 
Recipient have a Sequence Status Block 
for each concurrently active Sequence. 


3.1.109 Source: the N Port, identified by the 
Source _ Identifier (S_ID), from which the 
frame is transmitted. 


3.1.110 special character: any Transmission 
Character considered valid by the Trans- 
mission Code but not equated to a Valid 
Data Byte. Special Characters are pro- 
vided by the Transmission Code for use in 
denoting special functions. 


3.1.111 special code: a code which, when 
encoded using the rules specified by the 
Transmission Code, results in a Special 
Character. Special Codes are typically 
associated with control signals related to 
protocol management e.g., K28.5. 


3.1.112 spectral width full width half maximum 
(FWHM): the absolute difference between 
the wavelengths at which the spectral 
radiant intensity is 50 percent of the 
maximum power. 


3.1.113 spectral width lasers (RMS): the weighted 
root mean square (RMS) width of the 
Active Output Interface optical spectrum. 
(See FOTP-127.) 


3.1.114 synchronization: receiver identification of 
a Transmission-Word boundary established 
by a Transmitter on a Fibre. 


3.1.115 Transmission Character: any encoded 
character (valid or invalid) transmitted 
across a physical interface specified by 
FC-O. Valid Transmission Characters 
include Data and Special Characters and 
are specified by the Transmission Code. 


3.1.116 Transmission Code: a means of 
Encoding data to enhance its Transmission 
Characteristics. The Transmission Code 
specified by this standard is byte-oriented, 
with (1) Valid Data Bytes and (2) Special 
Codes encoded by this Transmission Code 
converted to 10-bit Transmission Charac- 
ters. 


3.1.117 Transmission Word: a string of four 
Transmission Characters treated as a unit. 


3.1.118 transmitter: the portion of a link Control 
Facility dedicated to converting Valid Data 
Bytes and Special Codes into Transmission 
Characters using the rules specified by this 
standard, converting these Transmission 
Characters into a bit stream, and transmit- 
ting this encoded bit stream onto a Fibre. 
In FC-0 transmitter (Tx) means an 
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optoelectronic circuit that converts an elec- 
trical logic signal to an optical signal. 


3.1.119 transceiver: A transmitter and receiver 
combined in one package. 


3.1.120 unrecognized ordered set: a Trans- 
mission Word containing a K28.5 Special 
Character in its first (leftmost) position but 
not defined to have special meaning by the 
standard. 


3.1.121 Upper Level Protocol (ULP): a higher 
level protocol user of FC-2. 


3.1.122 valid data byte: a string of eight bits 
passed to and from the FC-2 level as a 
unit. Typically a Valid Data Byte contains 
either binary information or a character 
encoded according to the character repre- 
sentation of the using node. 


3.1.123 Valid frame: a frame received with a valid 
SOF, a valid EOF, valid data characters, 
and proper CRC verification of the Frame 
Header and Data field. 


3.1.124 vendor unique: those features that can be 
defined by a vendor in a specific imple- 
mentation. Caution should be exercised in 
defining and using such features since they 
may or may not be standard between 
vendors. 


3.1.125 wander: deviations from the ideal timing 
of an event which occur at low frequencies. 
Deviations which occur at high frequencies 
are termed jitter. The frequency division 
between jitter and wander is usually made 
based on the capabilities of the clock 
recovery. Wander is assumed to be tracked 
by the clock recovery and does not directly 
affect the timing allocations within a bit 
cell. Jitter is not tracked by the clock 
recovery and directly affects the timing 
allocations in a bit cell. For Fiber Channel 
the frequency division between jitter and 
wander corresponds to the bit rate divided 
by 2 500. 


3.1.126 word: a sequence of four contiguous 
bytes. (See Transmission word.) 


3.1.127 World_Wide_Name: a unique world wide 
address up to 60 bits wide, administered by 
a Network _Address Authority such = as 
CCITT or IEEE, preceded with 4 bit wide 
Network_Address Authority identifier. (See 
19.4 and 23.5.10) 
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3.2 Editorial conventions 


In this standard, a number of conditions, mech- 
anisms, sequences, parameters, events, English 
text, states, or similar terms are printed with the 
first letter of each word in uppercase and the 
rest lowercase (e.g., Exchange, Class). Any low- 
ercase uses of these words have the normal 
technical English meanings. 


Numbered items in this standard do not repre- 
sent any priority. If prioritized, it will be specif- 
ically so indicated. 


The American convention of numbering is used 
i.e., the thousands and higher multiples are sep- 


ee 


arated by a comma and a period is used as the 
decimal point. This is equivalent to the ISO con- 
vention of a space and a comma. 


American IS0 
0.6 0,6 
1,000 1 000 
1,323,462.9 1 323 462,9 


In case of any conflict between figure, table, and 
text, the text takes precedence. 


In all of the figures, tables, and text of this docu- 
ment, the most significant bit of a binary quantity 
is shown on the left side. Exception to this con- 
vention is indicated at the appropriate section. 


4 Structure and concepts 


The Fibre Channel (FC) is logically a point-to- 
point serial data channel, structured for high 
performance capability. Physically, the Fibre 
Channel can be an interconnection of multiple 
communication points called N_ Ports, intercon- 
nected through a switching network, called a 
Fabric, or can be simply point-to-point. Fibre is 
a general term used to cover all physical media 
types supported by the FC Standard - such as 
glass, plastic and copper. 


Fiber Channel is structured as a set of hierar- 
chical functions as illustrated in figure 1. The 
Physical interface (FC-0) consists of transmission 
media, driver and receivers and their interfaces. 
The Physical interface specifies a variety of 
media, and associated drivers and receivers 


FC_4 Device 


FC 


FC-—2 Protocol 
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capable of operating at various speeds. The 
transmission code used is 8B/10B and specified 
in FC-1. The signaling protocol (FC-2) is per- 
formed through frames and specifies the rules 
and provides mechanisms needed to transfer 
block(s) of data from end-to-end. Device proto- 
cols constitute FC-4 which is the highest layer in 
the Fibre Channel structure. FC-3 provides ser- 
vices common to multiple device protocols 
(FC-4s) such as Striping and Multicast. 


Fibre Channel Physical layer (FC-PH) consists of 
related functions FC-0, FC-1, and FC-2. Each of 
these functions is described as a level. The 
standard does not restrict implementations to 
specific interfaces between these levels. 


~ | = — | 


ag ones Striping / Multicast 
Services 


SIgnaling Protocol 


FC—1 Code Transmlsslon Protocol FC—PH 


FC—O Physicol 


Interface 
(Drivers and Recelvers) 


Figure 1. Fiber Channel structure 
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Fibre Channel provides a method for supporting 
any number of Upper Level Protocols (FC-4s). 
The Link Application is required, whereas other 
FC-4s are optional. 


A Fibre Channel Node is functionally configured 
as illustrated in figure 2. A Node may support 
one or more N Ports and one or more FC-4s. 
Each N_ Port contains FC-0, FC-1 and FC-2 func- 
tions. FC-3 optionally provides the common ser- 
vices to multiple N_ Ports and FC-4s. 


Node 


Figure 2. Fibre Channel functional configuration 


4.1 FC-0 general description 


The FC-0 level of the standard describes the 
physical link of the Fibre Channel. The FC-0 
covers a variety of media and the associated 
drivers and receivers capable of operating at 
wide range of speeds. The FC-0 is designed for 
maximum flexibility and allows the use of a large 
number technologies to meet the widest range of 
system requirements. 7 


Each fibre is attached to a transmitter of a port 
at one end and a receiver of another port at the 
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other end (see figure 3). When a fabric is 
present in the configuration, a fibre may attach 
to an N_Port and an F_Port (see figure 4). Patch 
panels or portions of the active fabric 


An end-to-end communicating route may be 
made up of physical links of different technolo- 
gies. For example, it may have multimode fibre 
links attached to end ports but may have a 
single mode link in between as illustrated in 
figure Figure 5. In figure 6, a typical fibre 


channel building wire configuration is shown. 


Figure 3. FC-0 Link 


Figure 4. Fabric 
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4.2 FC-0 interface overview 
Figure 7 shows the cable plant topology. 


Figure 8 and figure 9 show possible implementa- 
tions of the transmitter and receiver, respec- 
tively. 


Interfaces “a” through ”e” are for reference only 
and are implementation dependent. Recom- 
mended interfaces are included in Appendix D. 


Figure 18 shows the nomenclature used by FC-0 
to reference various combinations of compo- 
nents. 


FC-0 operates with a BER of less than 10-12. 
Figure 5, FCO path 


Cable Plant 


Connector 
Plug | 
Tronamitter Receiver 
(Tx) 4 b | (Rx) 


Figure 7. FC-0 interface 


Transmitter 
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Figure 8. FC-0 transmitter interfaces 
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Figure 9. FC-0O receiver interfaces 
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4.3 FC-1 general description 


The Fibre Channel ensures that the transmission 
characteristics of information to be transmitted 
over a Fibre are sufficiently robust through the 


use of a Transmission Code. This Transmission | 


Code accepts unencoded data and converts it to 
a form which ensures that sufficient transitions 
are present on the encoded bit stream to allow 
clock recovery at the Receiver. Certain 
encodings specified by the Transmission Code 
have special characteristics which allow a 
Receiver to easily determine word alignment on 
the incoming bit stream. 


Transmitter and Receiver behavior is specified 
via a set of states and their interrelationships. 
These states are divided into Operational and 
Not Operational classes. Error monitoring capa- 
bilities and special operational modes are also 
defined for Operational Receivers and Transmit- 
ters. 


4.4 FC-2 general description 


The Fibre Channel (FC) is logically a point-to- 
point serial data channel, structured for high 
performance capability. Physically, the Fibre 
Channel can be an interconnection of multiple 
communication points called N_ Ports, intercon- 
nected through a switching network, called a 
Fabric, or can be simply point-to-point. Fibre is 
a general term used to cover all physical media 
types supported by the FC Standard - such as 
glass, plastic and copper. 


The FC-2 level serves as the transport mech- 
anism of the Fibre Channel. The transported 
data is transparent to FC-2 and visible to FC-3 
and above. 
The following defined and 
described: 


concepts are 


— The physical components of the channel and 
their relationship as a Physical model. 

— Modes of use of the channel in terms of half- 
duplex, duplex and dual-simplex communi- 
cation models. 

— Topologies based on 
absence of a Fabric. 

— Classes of service provided by the Fabric 
and the N_ Ports. | 

— General Fabric model | 

— Building Blocks and their hierarchy 

— Sequence and Sequence Identifier 


the presence or 
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— Exchange and Exchange Identifier 
— Exchange Status Block model 
— Segmentation and Reassembly 


A Request-Reply model is used in several 
clauses for illustration but other models are 
equally valid. 


4.5 FC-2 Physical model 


Figure 10 depicts the FC-2 Physical model and 
illustrates the FC-2 physical structure and com- 
ponents. The Fibre Channel (FC) physically con- 
sists a minimum of two Nodes, each with a 
minimum of one N_Port interconnected by a pair 
of Fibres - one outbound and the other inbound. 
at each N Port. This pair of unidirectional Fibres 
transmitting in opposite directions is referred to 
in this document as a Link. The Link is used by 
the ‘interconnected N_ Ports to perform data com- 
munication. 


Physical equipment such as a processor, con- 
troller, or terminal can be interconnected to 
other physical equipment through these Links. 
Attached physical equipment supports one or 
more Nodes and each Node contains one or 
more N Ports, with each N Port containing a 
Transmitter and a Receiver. 


The Physical model shown in figure 10 is inher- 
ently capable of simultaneous, symmetrical 
bidirectional flow. A Fabric may be present 
between the N Ports and some Fabrics may not 
support this type of flow. From the perspective 
of a given N Port, for instance A(1) or B(1), its 
Transmitter sends Data frames on the Outbound 
Fibre and its Receiver receives the responses on 
the Inbound Fibre. Data frames are throttled by 
flow control. 


An N Port logically performs only a_ point-to- 
point communication with another N_ Port at any 
given time. This statement is true regardless of 
the presence of Fabric. Nevertheless, multiple 
N_ Ports in a Node can simultaneously perform 
data transfers in parallel with single or multiple 
N_ Ports contained in one or more Nodes. This 
structure provides the attached equipment flex- 
ible mechanisms to perform simultaneous data 
transfers in parallel to, or from single, or mul- 
tiple equipment(s). 


Each N_ Port has a unique identifier used to iden- 
tify the N_ Port during communication. 


4.5.1 Node and N_Port identifiers 


Referring to figure 10, Node A consists of two 
N Ports represented as A(1) and A(2) and Node 
B of two N Ports represented as B(1) and B(2). 
Thus, single or multiple N_ Ports contained within 
an Node are represented by a set of N_ Port 
Identifiers. Each N Port is represented as an 
element of the set, for example, 
Node D as {D(1), D(2), ..., D(n)}. 


4.5.2 Link_Control_ Facility (LCF) 


Each LCF shall perform the logical and physical 
control of the Link for each mode of use and pro- 
vides the logical interface to the Originator 
and/or the Responder, as applicable to a com- 
munication model. 


Fabric 


N Port A(1) 


Outbound Fibre 


Legend: 
T = Transmitter 
R = Receiver 


Fabric 
Controller 
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4.6 Communication models 


An N Port transmits Data frames at the request 
of ULP(s) within its Node, and_ transmits 
Link_Control responses to Data frames that it 
receives from other N Port(s). An N_ Port 
receives Link Control responses to Data frames 
that it transmitted, and it receives Data frames 
from other N_Port(s). 


An N Port can operate in half-duplex, duplex, or 
dual-simplex modes as described below. 


— Half-duplex operation is defined as an 
N_ Port transferring Data frames in one direc- 
tion only, with Link Control frames flowing in 
the opposite direction. 

— Duplex operation is defined as an N Port 
simultaneously transmitting and receiving 
Data frames, with Link_Control frames 
flowing in both directions as well. 

— Dual-simplex operation is defined as an 
N_ Port both transmitting and receiving data, 
but not simultaneously. Data frames and 
Link_Control frames flow in both directions, 
but the flow is limited, possibly by a Fabric 
to a single direction at a time. 


N Port B(1) 


Inbound Fibre 


Outbound Fibre 


Inbound Fibre 


Outbound Fibre 


ie 
cf 


N Port B(2) 


A(1), A(2) = N Port addresses within Node A 
B(1), B(2) = N Port addresses within Node B 
Fibre = Any medium type supported by Fibre Channel 
LCF = Link_Control Facility 


Figure 10. FC-2 Physical model 
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4.7 Topology 


Topologies defined, based on the capability and 
presence or the absence of Fabric between the 
N_ Ports, are: 


— Point-to-point Topology 
— Single InBand Address Topology 


Attributes of a Fabric may restrict operation to 
certain communication models. In figures 11 
and 12, both the Inbound and Outbound Fibres 
are represented as a single line. 


4.7.1 Point-to-point topology 


The point-to-point topology, as shown in figure 
11, in which communication between N_ Ports 
occurs without the use of Fabric is defined as 
point-to-point. Here the communicating N_ Ports 
are directly interconnected by a single dedicated 
link. 


N Port A(1) N Port B(1) 


Link 


Figure 11. Point-to-point topology 


4.7.2 Single InBand Address topology 


This topology uses the Destination_ldentifier 
(D_ID) embedded in the frame header to route 
the frame through a Fabric to the desired desti- 
nation N Port. Figure 12 illustrates multiple 
N_ Ports interconnected by a Fabric. 


N Port N Port N Port 


N Port N Port N Port 


Figure 12. Single InBand Address topology 
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4.8 Classes of service 


Three Classes of service are defined. These 
Classes of service are distinguished primarily by 
the methodology with which the communication 
circuit is allocated and retained between the 
communicating N_ Ports and the level of delivery 
integrity required for an application. Certain 
Fabrics and/or N Ports may not support all 
Classes of service. 


4.8.1 Class 1 service - Dedicated 
Connection 


Class 1 is a service, which once established, 
shall be retained and guaranteed by the Fabric 
(i.e. Dedicated Connection). This service guar- 
antees full bandwidth available between two 
N_ Ports across the established connection. 


In Class 1, frames shall be delivered in the same 
order as they are transmitted by the Source 
N_ Port. 


4.8.2 Class 2 service - Multiplex 


Class 2 is a connectionless service with the 
Fabric multiplexing frames at frame boundaries. 


The transmitter shall transmit frames in a 
sequential order within a given Sequence. In 
Class 2, the Fabric may not guarantee the order 
of delivery and frames may be received out of 
order. ULPs using Class 3 are expected to 
provide the appropriate acknowledgements. 


In Class 2, the Fabric guarantees notification of 
delivery or failure to deliver, in the absence of 
link errors. In case of link errors, notification is 
not guaranteed (since the S_ID may not be error 
free). 


4.8.3 Class 3 service - Datagram 


Class 3 is a connectionless service with the 
Fabric multiplexing frames at frame boundaries. 
Class 3 supports only open-ended delivery 
where the destination N_ Port does not send any 
confirmation Link _Control frames on receipt of 
valid Data frame(s). 


In Class 3, the Fabric is expected to make a best . 
effort to deliver the frame to the intended desti- 
nation and shall not issue busy or reject to the 


Source if the Fabric is unable to deliver the 
frame. 


4.9 Intermix 


Intermix is an option of Class 1 service which 
allows interleaving of Class 2 and Class 3 
frames during an established Class 1 Connection 
between two N Ports. During a Class 1 Con- 
nection, an N Port capable of Intermix may 
transmit and receive Class 2 and Class 3 frames 
interleaved with Class 1 frames. Support for the 
Intermix option of Class 1 service shall be indi- 
cated during Login. An N Port shall be capable 
of receiving intermixed frames before it is 
allowed to transmit intermixed frames. 


In a point-to-point topology, both interconnected 
N_ Ports shall be required to support Intermix if 
Intermix is to be employed. In the presence of a 
Fabric, both the N Port and the Fabric Port 
(F_ Port) to which it is attached shall be required 
to support Intermix if Intermix is to be employed. 
Fabric support for Intermix requires that the full 
Class 1 bandwidth during a Dedicated Con- 
nection be maintained. Intermix permits the 
unused Class 1 bandwidth to be used for trans- 
mission of Class 2 and Class 3 frames. 


4.10 General Fabric model 


The primary function of the Fabric is to receive 
the frame(s) from a source N_ Port and route the 
frame(s) to the destination N Port whose 
address is specified in the frame(s). Each 
N_ Port is physically attached through a Link to 
the Fabric. FC-2 specifies the protocol between 
the Fabric and the attached N Ports. A Fabric is 
characterized by a homogeneous address space. 


All Fabrics shall specify the classes of service 
they support. However, Fabrics are allowed to 
provide the Class(es) of service through equiv- 
alent mechanisms and/or functions. Refer to the 
Fabric requirements (FC-F) document for these 
equivalent functions provided by some Fabrics. 
See 23.6 for Fabric specific service parameters. 


Figure 13 illustrates the general Fabric model. 
The model consists of the following major func- 
tional blocks and sub-blocks. 


— Bidirectional Fabric Ports (F_Ports) 
— Receive buffer 

— Connection Sub-Fabric 

— Connectionless Sub-Fabric 
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— Receive buffer queue management 
— Fabric Controller 


4.10.1 Fabric Ports (F_Ports) 


The Fabric model contains two or more Fabric 
Ports (F_Ports). Each F_Port can be attached to 
an N Port through a Link. Each F_Port is 
bidirectional and shall support one or more com- 
munication models. 


The receiving F_Port responds to the sending 
N Port according to the FC-2 protocol. The 
Fabric may or may not verify the validity of the 
frame as it passes through the Fabric (see 17.7). 
If the Fabric chooses to verify the validity and 


finds a frame to be invalid, it shall forward the 


frame to the destination if that frame could have 
been forwarded had the Fabric not performed 
the validity check (see 17.6.2). 


An F_Port may or may not contain a receive 
buffer for the incoming frame(s). If present, the 
receive buffer size determines the maximum 
frame size that the Fabric can handle for Class 2 
and Class 3 service and for the frame which 
establishes Class 1 service. (The receive buffer 
size is determined by the Login protocol.) 


The Fabric directs the frame to the proper out- 
going F_Port based on the N Port identifier 
(D_ID) embedded in the frame. In some Fabrics, 
the frame may be routed to all F_ Ports sup- 
ported by the Fabric. Refer to the Fabric 
Requirements (FC-F) document for description of 
this broadcast function provided by some 
Fabrics. The address translation and the routing 
mechanisms within the Fabric shall be trans- 
parent to N Ports and are not specified in this 
document. 


4.10.2 Connection based Sub-Fabric 


The Connection based Sub-Fabric provides Dedi- 
cated Connections between F_Ports and the 
N_ Ports attached to these F_Ports. Such Dedi- 
cated Connections shall be bidirectional and 
support full data rate concurrently in both 
directions. A Dedicated Connection shall be 
retained until a removal request is received from 
one of the communicating N_Ports. 


On receiving a request from an N_ Port for Class 


1 service, the Fabric shall establish a Dedicated 
Connection to the destination N_Port through the 
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Connection Sub-Fabric. The mechanisms used 
by the Fabric to establish the connection are 
transparent to FC-2. 


The Sub-Fabric is not involved in flow control 
which is managed end-to-end by N_Ports. 


If the Fabric is unable to establish a Class 1 
service, it shall return a Busy or a Reject with a 


Fabric 


Receive Queue Element(s) 


rejected, 


Connection 
Sub-Fabric 


valid reason code. Once the Class 1 service is 
established, all frames between the communi- 
cating N_Ports shall be routed through the same 
circuit and all responses are issued by N_ Ports. 


If two N_Ports are in Class 1 Connection, a Class 
1 connect request from another source shall be 
regardiess of Intermix support. If 
Intermix is supported and the Fabric receives a 


Receive Queue Element(s) 


a 


Congestion ° ° 
° ° Management ° ° 
e @ . @ 
® ® 


Receive Queue Element(s) 


F Port —V 
uF | 


Connectionless 
Sub-Fabric 


Fabric 
Legend: 
F Port - Bidirectional Fabric Port R - Receiver 
RBUF - Receive Buffer T - Transmitter 


Figure 13. General Fabric model 
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Class 2 or Class 3 frame from another N_ Port, 
destined to one of the N Ports connected in 
Class 1, the Fabric may 


— allow delivery if the associated exit F_Port is 
not transmitting other frames, or 
— disallow delivery if the F_Port is transmitting. 


If the disallowed frame is Class 2, the transmit- 
ting N_ Port shall be notified. The exit F_Port 
may be able to hold the frame for a period of 
time before discarding the frame or returning a 
busy. lf it is Class 3, no notification shall be 
sent. 


4.10.3 Connectionless Sub-Fabric 


A Connectionless Sub-Fabric is characterized by 
the absence of Dedicated Connections. The 
Connectionless Sub-Fabric multiplexes frames at 
frame boundaries between an F_Port and any 
other F_Port and between the N Ports attached 
to them. 


The Fabric shall notify the transmitting N_ Port 
with a reason code if it is unable to deliver a 
Class 2 frame. In the case of a Class 3 frame, 
the Fabric shall not notify the transmitting 
N_ Port. 


A given frame flows through the Connectionless 
Sub-Fabric for the duration of the routing. Once 
the routing is complete, the Connectionless Sub- 
Fabric has no memory of the routing or the des- 
tination. 


When frames from multiple N Ports are targeted 
for the same destination N Port as in Class 2 
and Class 3, congestion of frames may occur 
within the Fabric. Management of this con- 
gestion is part of the Connectionless Sub-Fabric 
and buffer-to-buffer flow control. 


If an N Port breaks flow control rules which 
would cause overflow, the Fabric may discard 
the overflow frame without notification and shall 
log the error. 


4.10.4 Fabric Controller 


A Fabric Controller controls and coordinates all 
Fabric functions. It is an FC-2 addressable 
N_ Port with a well-known address. 
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4.11 Building Blocks 


A set of building blocks, their interrelationships, 
behavior rules and usage hierarchy are defined 
in FC-2. These building blocks are: 


— Frame 

— Sequence 
— Exchange 
— Protocol 


4.11.1 Frame 


Frames are based on a common frame format. 
Frames are broadly categorized as Data Frames 
and Link_Control frames. Data_Frames may be 
used as Link_Data frames or Device Data 
frames. (see 20.2). Link _Control frames are 
further classified as Acknowledge (ACK) frames 
and Link Response (Busy and Reject) frames. 
(see 20.3). 


Selective retransmission of frames (i.e., retry 
partial Sequence) for error recovery is not sup- 
ported in this standard. But busy conditions 
which are part of operating protocols need 
retransmission of busied frames up to its ability 
to retry. 


4.11.2 Sequence 


A Sequence is a set of one or more related 
Data_Frames transmitted unidirectionally from 
one N_ Port to another N_ Port with corresponding 
Link_Control frames, if applicable, transmitted in 
response. It may be used as a Request or a 
Reply Sequence. An N Port which initiates a 
Sequence is referred to as the Sequence Initi- 
ator and the N_ Port which responds to the initi- 
ation of a Sequence as the Sequence Recipient. 
Usage rules for these Sequences are specified 
in “24 Exchange, Sequence, and Sequence 
Count Management.” 


Error recovery is performed at the Sequence 
boundary. If a frame is not transmitted error 
free, and error policy requires error recovery, 
the Sequence to which the frame belongs shall 
be retransmitted. (See 29.) 
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4.11.2.1 Sequence_Identifier (SEQ_ID) 


The Sequence Initiator (which — transmits 
Data Frames) shall assign the Sequence a 
Sequence Identifier (SEQ ID). The Sequence 
Recipient shall use the same SEQ ID in its 
response. This N Port pair shall have only one 
SEQ_ID active per Exchange Identifier at any 
given time. (See 4.11.3.1.) In other words, an 
N_ Port may initiate multiple Sequences for mul- 
tiple Exchanges but only one SEQ_ID shall be 
active for a given Exchange Identifier ’irrespec- 
tive of direction” at any given time. 


4.11.2.2 Sequence Status Blocks 


A Sequence Status Block is a logical construct 
representing the format of the status information. 
It is used to track the progress of a Sequence at 
an N_ Port on a frame by frame basis. A 
Sequence Initiator Status Block and a Sequence 
Recipient Status Block are used by the respec- 
tive N Port to track the status of a given 
Sequence. 


— When a_ Sequence Initiator starts a 
sequence, the Sequence Initiator shall allo- 
cate a Sequence Status Block to be associ- 
ated with the SEQ ID it has assigned. 

— The Sequence Recipient also shall allocate a 
Sequence Status Block at its end, associated 
with the SEQ ID the Sequence Initiator has 
allocated. 

— Both the Sequence Initiator and Sequence 
Recipient N_Ports track the status of this 
Sequence through the Sequence Initiator and 
the Sequence Recipient Status Blocks 
respectively. 


The maximum number of concurrent Sequences 
(SEQ IDs) the Sequence Initiator may initiate 
with a given destination is limited by the number 
of Recipient Sequence Status Blocks provided by 
the service parameter of that destination. This 
value is established during Login through the 
service parameters (See “23 Login and Service 
Parameters”). 
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4.11.3 Exchange 


Exchanges are composed of one or more non- 
concurrent Sequences. An Exchange is the 
basic mechanism used to transfer data between 
two N_ Ports (or Nodes). An Exchange may be 
unidirectional, or bidirectional. A unidirectional 
Exchange results if Sequence(s) within the 
Exchange perform information transfer in a 
single direction. A bidirectional Exchange 
results if Sequence(s) within the Exchange 
perform information transfer in a both directions. 
An Exchange may span across one or more 
Class 1 Connections. 


4.11.3.1 Exchange_Identifiers (OX_ID and RX_ID) 


Exchange Identifiers shall be used by the Origi- 
nator and Responder to uniquely identify an 
Exchange. 


— The Originator shall assign each new 
Exchange an Originator Exchange _ Identifier 
(OX_ID) unique to the Originator and embed 
it in all frames of the Exchange. 

— The Responder shall assign a Responder 
Exchange _ldentifier (RX_ID) unique to the 
Responder in response and shall communi- 
cate it to the Originator before the end of 
first Sequence of the Exchange. The 
Responder embeds the RX_ID along with 
OX_ID in all subsequent frames of the 
Exchange. 

— On receiving the RX_ID from the Responder, 
the Originator shall embed both the RX_ID, 
and OX_ID.in all subsequent frames of the 
Exchange. 


The Originator may initiate multiple concurrent 
Exchanges, but each shall use a unique OX_ID. 


4.11.3.2 Exchange Status Blocks 


An Exchange Status Block is a logical construct 
representing the format of the Exchange status 
information. It is used to track the progress of 
an Exchange on a Sequence by Sequence basis, 
An Originator Exchange Status Block and a 
Responder Exchange Status Block are respec- 
tively used by an Originator and a Responder to 
track the status of an Exchange. 


— When an Originator initiates an Exchange, it 
shall assign an Originator Exchange Status 
Block associated with the OX_ID it has 
assigned to the Exchange (See 29.11.3). 


— The Responder shall assign a Responder 
Exchange Status Block associated with the 
OX_ID the Originator has assigned to the 
Exchange. The Responder may reference it 
through the respective RX_ID the Responder 
optionally assigns or through the OX_ID (See 
29.11.3). 


— Both the Originator and the Responder shall 
track the status of the Exchange at their 
respective N Ports via these Exchange 
Status Blocks. 


4.11.4 Protocol 


This standard provides and describes data 
transfer protocols and rules to be used by higher 
level protocols to accomplish a given level of 
function. This standard also provides Login and 
Logout control functions to manage the oper- 
ating environment to perform data transfers. 


— Fabric Login protocol: An N Port shall 
establish a Class of service with the Fabric if 


Fabric Fabric 
service service 
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any, by explicitly performing the Fabric Login 
protocol “or implicitly” through an equivalent 
method not defined in this standard. 

— N Port Login protocol: Before performing a 
Class 1 or Class 2 data transfer, the N_Port 
shall interchange its service parameters with 
the other N Port through an N Port Login 
protocol. (See 23.5 for the definition of 
service parameters). 

— Data transfer protocol: The actual data 
transfer shall use Data transfer protocols. 
Examples are provided in Annex &dtp.. 

— N Port Logout protocol: An N Port may 
request removal of its service parameters 
from the other N Port by performing an 
N Port Logout protocol. This request may 
be used to free up resources at the other 
N_ Port. 


4.11.5 Usage hierarchy 


These FC-2 building blocks are used in a hierar- 
chical fashion, as illustrated in figure 14. 


Fabric Fabric 
service service 


Lcmacuepcnntnliesanunnt a 


N Port N Port 
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DATA. 
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protocol 
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frame; eee frame frame! |} frame/ | frame frames 


Figure 14. FC-2 building blocks hierarchy 
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4.12 Segmentation and Reassembly 


Segmentation and Reassembly are the FC-2 
functions provided to subdivide a block of data to 
be transferred into smaller “data segments”, 
embed each “data segment” in an individual 
frame as the payload, transfer these frames over 
the channel, and reassemble the block of data at 
the receiving end. 


In FC-2, the maximum payload size in each 
frame is governed by the receive buffer sizes of 
the Fabric and the destination N Port. The 
Payload of a frame is allowed to be of equal or 
varied size within this maximum. 


FC-2 Segmentation and Reassembly processes, 
along with ULP gather and scatter processes, 
are illustrated in figure 17. 


4.12.1 Application data 


Upper level protocols (ULPs) have the know- 
ledge of the amount of application data to be 
transferred. The application data may be contig- 
uous or scattered in memory. The ULP shall 
specify the Payload for the last frame to be 
transferred in its entirety to FC-2, before FC-2 
starts the transfer of the last frame. 


4.12.1.1 Application data Mapping 


A block of data may be mapped to FC-2 as one 
or more Sequences. Multiple blocks of data may 
be mapped to FC-2 as a single Sequence. 
Mapping blocks of data to Sequences at the 
sending end and Sequences to blocks of data at 
the receiving end are outside the scope of this 
standard but are performed within the N_Ports. 
Examples of mapping blocks of data are illus- 
trated in figures 15 and 16. 
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Figure 15. Mapping a block of data to multiple 
Sequences 
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Figure 16. Mapping multiple blocks of data to a 
single Sequence 
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4.12.2 Sending end ULP 


The sending end ULP shall completely specify 
each block of data, e.g., with starting address, 
ending address, size etc. 


4.12.2.1 Offset 


Offset is an FC_2 construct used at the sending 
ULP to indicate the displacement of the first data 
byte of each frame’s payload with reference to 
the base address at the sending end for a block 
of data. The sending end ULP may provide FC-2 
an initial Offset for each block of data. If a par- 
ticular ULP does not provide an initial Offset, a 
value of all ones shall be used by FC-2. (The 
receiving end ULP shall be able to reassemble 
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Figure 17. Segmentation and Reassembly 


the application data without the aid of the offset 
value.) 


4.12.2.2 Segmentation 


“Segmentation” is the process by which FC-2 
subdivides a block of data to be transferred into 
frames with payloads of equal or varied sizes 
and transmits them over the Link. During Seg- 
mentation, FC-2 determines the size of the 
payload for each frame in the Sequence. It 
embeds the data in the payload of the frame 
along with the Offset of the Payload “’relative to 
the initial Offset of the block of data” and trans- 
fers each frame to the destination N_ Port. 


4.12.3 Receiving ULP 


The receiving end ULP receives application data 
from the sending ULP as FC-2 Sequence(s). 


4.12.3.1 Offset 


The Offset within each frame is the displacement 
of the first data byte of the payload in that frame, 
with reference to the base address of the 
receiving ULP for the block of data. 


4.12.3.2 Reassembly 


Reassembly is the FC-2 process which reassem- 
bles a block of data by placing the Payload from 
each frame at the Offset specified in the frame. 
The receiving ULP may receive the data contig- 
uously or scattered within its application 
buffer(s). 


4.13 Error detection and recovery 


In general, detected errors fall into two broad 
categories: frame errors and link-level errors. 
Frame errors result from missing or corrupted 
frames. Corrupted frames are discarded and the 
resulting error is detected at the Sequence level. 
At the Sequence level, an out of sequence frame 
is detected or the Sequence times out due to 
one or more missing Data frames or Acknowl- 
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edgments. Once detected, the Sequence is 
aborted and the Sequence is_ retransmitted. 
Sequence errors may also cause Exchange 
errors which may also be aborted. Selective 
error recovery is performed on the failing 
sequence or Exchange. Other properly per- 


forming Sequences are unaffected. 


Link-level errors result from errors detected at a 
lower level of granularity than frames where the 
basic signal characteristics are in question. 
Link-level errors include such errors as loss of 
signal, loss of synchronization, and several link 
timeout errors which indicate no frame activity. 
When link-level errors are detected by the 
receiver, it is not possible to determine if the 
error was caused by receiver logic, the trans- 
mission medium, the transmitter logic, or the 
remotely attached Port. Recovery from link-level 
errors is accomplished by transmission and 
reception of Primitive Sequences. Recovery at 
the link-level disturbs normal frame flow and 
may introduce Sequence errors which must be 
recovered following recovery at the link-level. 


Primitive Sequences are low-level Ordered Sets 
which provide word synchronization and a hand- 
shake mechanism in order to ensure that both 
the transmitter and receiver are able to transmit 
and receive “primitive” signals. Primitive 
Sequence protocols are specified for Link 
Failure, Link Initialization, Link Recovery, and 
Online-to-Offline transition. 
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4.13.1 Error recovery hierarchy 


The recovery of errors may be described by the 
following hierarchy: 


Abort Exchange 
(Abort Exchange Protocol-frames) 


Abort Sequence 
(Abort Sequence Protocol-frames) 


Link Reset 
(Link Recovery Protocol-primitives) 


Link Failure 
(Link Failure Protocol-primitives) 


Link Initialization 


(Link Init Protocol-primitives) 


American National Standard 
for Information Systems 
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FC-0 level - Physical interface and media 


5 FC-0 functional characteristics 


The FC-0O describes the lowest level physical link 
in the Fibre Channel system. It is designed for 
maximum flexibility and allows the use of a large 
number of technologies to meet the widest 
variety of system requirements. 


5.1 General characteristics 


FC-0 has the following general characteristics. 


— Serial data streams are supported at data 
rates of 132,812 5 MBit/s, 265,625 MBit/s, 
531,25 MBit/s and 1,062 5 GBit/s. All data 
rates have clock tolerances of +100 ppm. 


— A system bit error rate (BER) < 10-12 is sup- 
ported. 


— The interoperability specifications are at the 
external interface as shown at points S and 
R in figure 7. 


— The interface to FC-1 occurs at the serial 
data interfaces. For the transmitter this is 
point b in figure 8. In the case of the receiver 
the interface is the retimed serial data indi- 
cated at point d in figure 9. Additional points 
are discussed and recommended in the 
annexes. 


The physical links have the following character- 
istics: 


— Physical point to point data links. 


— Any transmitter is always connected to the 
same receiver, optical switches are not sup- 
ported. | 


— An elastic buffer is required at all nodes in 
the switch fabric or repeaters. All signals 
must be retimed before retransmission to 
prevent jitter accumulation. 


— All specifications are end-of-life worst case 
values over manufacturing, temperature, 
power supply and cable plant variations. 


The interface between FC-0 and FC-1 is inten- 
tionally structured to be technology and imple- 
mentation transparent. That is, the same set of 
commands and services may be used for all 


signal sources and communications media. The 


intent is to allow for the interface hardware to be 
interchangeable at the system level without 
regard to the technology of a particular imple- 
mentation. As a result of this, all safety or other 
operational considerations which may be 
required for a specific communications tech- 
nology are to be handled by the FC-0 level asso- 
ciated with that technology. An example of this 
would be the open fibre control system required 
for the short wave laser technologies as dis- 
cussed in section 6.2.3. 


5.2 FC-0 States 


5.2.1 Transmitter States 


The transmitter is controlled by the FC-1 level. 
lts function is to convert the serial data received 
from the FC-1 level into the proper signal types 
associated with the operating media. 


— Transmitter Not-Enabled State: A not- 
enabled state is defined as the optical output 
off for optical communication media and a 
logical zero for coaxial media. This is the 
state of the transmitter at the completion of | 
power on sequence unless the transmitter is 
specifically directed otherwise by the FC-1 
level. 


— Transmitter Enabled State: The transmitter 
shall be deemed to be in an enabled state 
when the transmitter is capable of operation 
within its specifications while sending valid 
data patterns. 


— Transition Between Not-Enabled and Enabled 
States: The sequence of events required for 
the transition between the not-enabled and 
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enabled states will be media dependant, 
both as to the time period required and the 
optical or logical activity on the media inter- 
face. 


— Transmitter Failure State: Some types of 
transmitters are capable of monitoring them- 
selves for internal failures. Examples are 
laser transmitters where the monitor diode 
current is may be compared against a refer- 
ence to determine proper operating point. 
Other transmitters, such as Light Emitting 
Diodes and coaxial transmitters do not typi- 
cally have this capability. If the transmitter 
is capable of performing this monitoring 

_ function then a detection of a failure shall 
cause entry into the failure state. 


5.2.2 Receiver States 

The function of the receiver interface is to 
convert the incoming data from the form 
required by the communications media 
employed, retime the data, and present the data 
and an associated clock to the FC-1 level. 


The receiver has no states. 


5.3 Response to input data phase 
jumps 


Some link implementations may have phase dis- 
continuities in the incoming data. This may 
occur from causes such as the operation of a 
serial switch at the transmitter. In the event of 
such a phase discontinuity the recovery charac- 
teristics of the receiver shall be specified as 
follows: 


Phase Jump 


Uniform distribution between +180° 
Link Worst Case 


Degree of Recovery 
Within BER objective (10-2) 


Probability of Recovery 
95% 
Recovery Time 
2 500 baud intervals 


Additional Wait Time Before Next Phase Jump 
None 


The FC-0 level shall require no intervention from 


higher levels to perform this recovery. If, at the 
end of the specified time, the higher levels 
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testing or other purposes. 


determine that bit synchronization is not present 
these levels may assume a fault has occurred 
and take appropriate action. 


5.4 Limitations on invalid code 


The FC-0 is intended to operate with valid 
8B/10B encoded data supplied by the FC-1. 
However, it is recognized that it may occa- 
sionally be desired to pass invalid data for 
This may be done 
without upseting the operation of the FC-0 within 
the following limitations: 


1. No more than two (2) bytes of invalid data 
may occur within a group of thirty two (32) 
bytes. 


2. There must be at least thirty two (32) byte of 
valid data between bytes of invalid data. 


3. lvalid data bytes are limited to a balance 
between 40% and 60%. The maximum run 
length is limited to twelve (12) consecutive 
ones or zeros. 


4. The invalid data may occur only after bit 
synchronisation has been acheived. 


5.5 Receiver initialization time 


The time interval required by the receiver from 
the initial receipt of a valid input to the time that 
the receiver is synchronized to the bit stream 
and delivering valid retimed data within the BER 


' objective of the system shall not exceed 1 milli- 


second. Should the retiming function be imple- 
mented in a manner that requires direction from 
a higher level to start the initialization process, 
the time interval shall start at the receipt of the 
initialization request. 


5.6 Signal detect function 


The FC-0 may optionally have a signal detect 
function. If implemented this function shall indi- 
cate when the receiver has determined that the 
signal on the input is above a predetermined 
level. In the case of optical media the activation 
level will lie in a range whose upper bound is 
the minimum specified sensitivity of the receiver 
and whose lower bound is the lower of either the 
point where the bit error rate will exceed 10-2 or 
7 dB below the minimum receiver sensitivity. 


While there is no defined hysteresis for this func- 
tion there shall be a single transition for any 
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monotonic increase or decrease in the optical 
power. The optical power at the transition points 
shall lie within the previously defined bounds. 


100-SM-LL-L 


speed distance 
For optical links that employ a link control func- 100 100 MByte/s L long distance 
tion, such as annex Annex H, the signal detect 50 50 MByte/s | intermediate 
is replaced by the link status function as pro- 25 25 MByte/s distance 
Sid nis Iace ARE SEER. 12 12,5 MByte/s S short distance 
media transmitter 
The reaction time to a change in the input eH nde aoa SI ug ave rae 
multi-mode short wave laser 
optical power shall be less than 12 seconds. (50pm) LE long wave LED 
M6 multi-mode SE short wave LED 
5.7 FC-0 nomenclature (62.5ym) TV CATV cable 


CX coaxial cable MI miniature cable 


The nomenclature for the technology options are | 


; ; Figure 18. FC-0 nomenclature 
illustrated in figure 18. 


| 5.8 FC-0 technology options 


FC-0 provides for a large variety of technology 
options. Tables 1 and 2 list the presently sup- 
ported signal interface types, both optical fibre 
and coaxial. For each listing the nomenclature is 
listed along with a reference to the section 
within this standard containing detailed informa- 
tion. There is also a brief description indicating 
the technology and the nominal communication 
distance. 


Table 1. Fibre Media Signal Interface 


100 MB/s 1,062 5 GBit/s | 


100-SM-LL-L 100-SM-LL-! 
Section 6.1 Section 6.1 
SM SM 


1 300nm 1 300nm 
2m-10Km 


50 MB/s 531,25 MBit/s 


50-SM-LL-L 50-M5-SL-I 
Section 6.1 Section 6.2 


25-SM-LL-L 25-SM-LL-I 25-M6-LE-| 25-M5-SL-I 
Section 6.1 Section 6.1 Section 6.3 Section 6.2 
SM MM(LED) 

1 300nm 1 300nm 

2m-10Km 0-1Km 


12,5 MB/s 132,812 5 MBit/s 


.12-M6-LE-! 
Section 6.4 
MM(LED) 
1 300nm 
0-500m 
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Table 2. Coaxial Media Signal Interface 


50-CX-TV-S © 
Section 7.2 


100-CX-TV-S 


Section 7.2 


0-50m 0-50m 0-50m 


Tables 3 and 4 give information concerning the 
presently supported communications media 
types, both optical fibre and coaxial. Each signal 
type has an associated primary media type. 
However, in some cases the there is a listing for 


25-CX-TV-S 
Section 7.2 


12-CX-TV-S 
Section 7.2 


0-50m 


an alternate cable plant which may be used with 
degraded performance. For more information on 
alternate cable plants see Annex B~ and 
Annex E. 


Table 3. Fibre Cable Plant. 
(****** indicates alternate cable plant, see Annex B) 


Single Mode 


100-SM-LL-L 


Section 6.1 


50-M6-SL-I 
Section 6.2 


50-M5-SL-| 
Section 6.2 


CATV Coax 


100-CX-TV-S 


Section 7.2 


0-50m 


Miniature Coax 


100-CX-MI-S 


Section 7.3 


0-10m 


KaAKKKKK 
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100-SM-LL-|! 
Section 6.1 


25-M6-SL-] 
Section 6.2 


KRARKKKKKK 


25-M5-SL-| 
Section 6.2 


50-CX-TV-S 
Section 7.2 


0-50m 


50-CX-MI-S 


Section 7.3 


0-10m 


KkeaKKKK 


50-SM-LL-L 
Section 6.1 
SM 

1 300nm 


—2m-10Km 


25-M6-LE-I 
Section 6.3 
MM(LED) 

1 300nm 
0-1Km 


25-M5-LE-l 
Section 6.3 
MM(LED) 
1 300nm 


raKRKKRKKKK 


25-CX-TV-S 
Section 7.2 


0-50m 
25-CX-MI-S 
Section 7.3 


0-10m 


aka KKKK 


25-SM-LL-L 
Section 6.1 
SM 

1 300nm 
2m-10Km 


12-M6-LE-| 
Section 6.4 
MM(LED) 

1 300nm 
0-500m 


12-M5-LE-I 
Section 6.4 
MM(LED) 
1 300nm 


KAKRKKRKK 


Table 4. Coaxial Cable Plant. 
****** indicates alternate cable plant, see Annex E&) 


12-CX-TV-S 
Section 7.2 


0-50m 


12-CX-MI-S 


Section 7.3 


0-10m 


rake 


25-SM-LL-I 
Section 6.1 
SM 

1 300nm 
2m-2Km 
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6 Fibre interface specification 


This section defines the interfaces of the serial | on a requirement that the bit error rate (BER) < 
optical signal at the interconnect receptacles. | 10-12 be maintained under all conditions of this 
Each conforming FC attachment shall be compat- | section, including the minimum active input 
ible with this serial optical interface to allow interface power level. The corresponding cable 
interoperability within an FC environment. The plant specifications are described in section 8. 


parameters specified in this section are based 


| Table 5. FC-0 physical links for single mode classes 

| 100-SM 100-SM 50-SM 25-SM 25-SM 

| -LL-L ial l -LL-L -LL-L -LL-I 
a a ae a ee ee PI es | 


Section ; 6.1 6.1 
Data Rate MB/sec 25 25 
Nominal Bit Rate MBit/s ; ; 265,625 265,625 
Tolerance + + + +100 +100 
Operating Range (typ) - - - 2-10K 2-2K 


Fibre type 


Transmitter(S) 


Type 


Spectral Center Wavelength nm (min) 
| nm (max) 


| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| RMS Spectral Width nm (max) 
| Launched power, max dBm (ave) 
| Launched power, min dBm (ave) 
| Extinction Ratio dB (min) 
| 

| 

| 

| 

| 

| 

| 

| 

| 


RIN dB/Hz 
12 (max) 


Eye Opening @ BER=10 % 
-12 


Receiver (R) 


Received power, min dBm (ave) -25 -20 -25 -25 -20 
Received power, max. dBm (ave) -3 -3 -3 -3 -3 
AC optical path penalty dB (max) 2 2 2 2 2 
Return loss of receiver dB (min) 12 12 12 12 12 


25-M5 25-M6 12-M6 
-SL-I -LE-! -LE-I 
PAT I. PT aa 


Section _ 6.4 


Data Rate MB/sec 25 12,5 
Nominal Bit Rate MBit/s ; 265,625 132,813 
Tolerance + +100 +100 
Operating Range (typ) - 0-1K 0-500 
Fibre type 62,5 62,5 
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Table 6 (Page 2 of 2). FC-0 physical links for multi-mode classes 


| Fc-0 © 50-M5 25-M5 25-M6 12-M6 
-SL-] -SL-I -LE-I -LE-I 
Ce EI, [EPR Se, (PRE EE CET] KER NAEa RC (CAE aC E EE ROE SUR RAMM MERE CEANO Ene GONG RNa Nema 
Type 


Spectral Center Wavelength nm (min) 
nm (max) 


LED LED 


Spectral Width nm (max) 
RMS/FWHM 


Launched power, max dBm (ave) 
Launched power, min dBm (ave) 


Extinction Ratio dB (min) 


RIN dB/Hz 
12 (max) 


Eye Opening @ BER=10 % 
-12 


Deterministic jitter % (p-p) 
Random Jitter % (p-p) 


Optical Rise/Fall Time ns (max) 


Received power, min dBm (ave) 


Received power, max dBm (ave) 
Return loss of receiver dB (min) 
Discrete Conn return loss dB (min) 
Determnistic jitter % (p-p) 
Random Jitter % (p-p) 


Optical Rise/Fall Time ns (max) 


6.1 SM data links 


Table 5 gives the link budgets for 2 and 10 km 
single mode optical fiber links running at 266, 
531, and 1 062 MBit/s. The optical power 
coupled into the fiber is limited to a maximum 
value consistent with Class 1 laser safety opera- 
tion per IEC 825, "Radiation safety of laser pro- 
ducts, equipment classification, requirements 
and user’s guide”. 


yl 


Normalized Amplitude 


6.1.1 Optical output interface 


Table 7. Eye diagram mask table 
| Rates 


266 MBit/s 


0 x1 x2 1-x2 1-x!1 1 
Normalized Time 


Figure 19. Eye diagram 


| The general laser transmitter pulse shape char- 
| acteristics including rise time, fall time, pulse 
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overshoot, pulse undershoot, and ringing, all of 
which should be controlled to prevent excessive 
degradation of the receiver sensitivity are speci- 
fied in the form of a mask of the transmitter eye 
diagram at point S. For the purpose of a 
assesment of the transmit signal, it is important 
to consider not only the eye opening, but also 
the overshoot and undershoot limitations. The 
parameters specifying the mask of the trans- 
mitter eye diagram are shown in figure 19 and 
table 7. Annex A considers measurement 
setups for determining the eye diagram of the 
optical transmit signal. 


6.1.2 Optical input interface 


The receiver shall operate at a BER < 10-12 when 
the input power falls in the range given when 
driven with a data stream output that fits the 
specified eye diagram mask. 


Receiver characteristics specified in this docu- 
ment are receiver sensitivity, overload, receiver 
reflectance, and the allowable power penalty 
from the combined effects of dispersion, 
reflections, and jitter. 


The minimum and maximum values of the 
average received power in dB give the input 
power range to maintain a BER < 10:''2. These 
values take into account power penalties caused 
by the use of a transmitter with worst-case, end 
of life, transmitter spectral, extinction ratio, and 
pulse shape characteristics specified for each 
application described, 


The optical path power penalty (in dB) accounts 
for the total degradation along the optical path 
(from reflections, jitter, and the combined effects 
of dispersion resulting from intersymbol interfer- 
ence, mode-partition noise, and laser chirp). 


The minimum acceptable value for receiver sen- 
sitivity shall equal the values specified in table 5. 
In addition, the receiver shall be designed to 
accommodate the dispersion power penalty. 


The receiver overload shall equal or exceed the 
value given in table 5. 
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6.2 SW laser data links 


The first two columns of table 6 give the link 
budget for short wavelength (SW) laser data 
links at 531 and 266 Mbit/s on multi-mode fibre. 


6.2.1 Optical output interface 
The Active Output interface shall exhibit the 
characteristics as shown in table 6. 


Table 6 gives the link budgets, transmitter spec- 
ifications, and receiver specifications for the 
short wavelength (SW) laser links operating at 
the 531,25 and 265,625 Mbit/s rates. The SW 
laser described for this link is the self-pulsating 
type, which provides a low noise transmitter 
source that essentially eliminates the problems 
of modal noise and laser reflection noise on the 
multi-mode fibre. 


The self-pulsation frequency should be greater 
than three times the bit rate of the link to allow 
for efficient filtering of the self-pulsation noise. 
The self-pulsation frequency of most self- 
pulsating lasers will shift upward over a limited 
range with increased drive current. Hence, it is 
desirable to operate the SW laser for the 531 
Mbit/s data link at a slightly higher power level 
than the 266 Mbit/s link. 


The maximum and minimum of the allowed 
range of average transmitter power coupled into 
the fibre are worst-case values to account for 
manufacturing variances, drift due to temper- 
ature variations and aging effects, and operation 
within the specified minimum value of the 
extinction ratio. 


The minimum value of the extinction ratio shall 
be the minimum acceptable value of the ratio (in 
dB) of the average optical energy in a logic one 
level to the average optical energy in a logic 
zero level. It shall be measured under fully 
modulated conditions in the presence of worst- 
case reflections. 


The transmitter eye diagram requirements are 
identical to those presented in 6.1.1. The (nor- 
malized) mask of the transmitter eye diagram is 
shown in figure 19, and specified in table 7. The 
values given in this table are the same for both 
the 531 and 266 MBit/s SW laser transmitters of 
this section. 
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6.2.2 Optical input interface 


The receiver shall operate at a BER of 10°'2 over 
the link’s lifetime and temperature range when 
the input power falls in the range given in table 
6 and when driven with a data stream output 
that fits the specified mask of the eye diagram. 


Receiver characteristics specified in this docu- 
ment are receiver sensitivity, overload, receiver 
reflectance, and the allowable power penalty 
from the combined effects of dispersion, 
reflections, and jitter. 


The minimum sensitivity and maximum overload 
values of the average received power in dBm 
give the input power range over which a 10-12 
BER is achieved. These values take into 
account power penalties caused by the use of a 
transmitter with worst-case transmitter spectral, 
extinction ratio, and pulse shape characteristics 
specified for each application described, and 
they include the effects of drifts due to temper- 
ature variation and aging. 


The optical path power penalty (in dB) typically 
accounts for the total degradation along the 
optical path (from reflections, jitter, and the com- 
bined effects of dispersion resulting from inter- 
symbol interference, mode-partition noise, and 
laser chirp). However, for multi-mode fibre data 
links (with both laser and LED sources), a 
common practice is to include or incorporate 
this optical path power penalty into the actual 
link budget specifications of both the power 
budget (producing amplitude degradation) and 
the timing budget (producing pulse spreading 
degradation). Therefore, the SW laser data links 
have no specified optical path power penalty 
(not included in table 6) because these link degr- 
adations of both amplitude and pulse spreading 
(primarily modal dispersion) are already 
“accounted for” in the power budget and time 
budget as specified between the transmitter and 
receiver in table 6. 


The minimum acceptable value for receiver sen- 
sitivity shall equal the values specified in table 6. 
In addition, the receiver shall be designed to 
accommodate the maximum received power and 
the optical rise/fall time at the input to the 
receiver. The receiver overload shall equal or 
exceed the value given in table 6. 
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6.2.3 The Open Fibre Control Safety 
System (OFC) 


An overview of an open fibre link detection and 
laser control system referred to as the Open 
Fibre Control (OFC) system is presented in this 
section. This laser control system can be used 
as a safety interlock for point-to-point optical 
fibre links that use semiconductor laser diodes 
as the optical source. The main reason for 
implementing this safety interlock system is that 
the optical power levels required to obtain the 
desired level of system performance would 
exceed the Class 1 limits defined by one or more 
national or international laser safety standards 
in the event that the optical fibre link between 
two optical ports is disconnected (i.e., an opened 
connector or cut fibre). Meeting the require- 
ments for Class 1 classification is very important 
for an optical interconnect system in a computer 
environment due to the potential for customer 
exposure to laser radiation. Simply certifying 
the laser system at a higher classification level 
is impractical unless access can be restricted to 
only trained service personnel. 


The following description of the OFC system 
applies to both the 531 Mbit/s and 266 Mbit/s SW 
laser data links. For purposes of this standard, 
the OFC timings have been chosen to be the 
same for both data rates. The timings are, 
however, based upon the higher allowed optical 
power levels of the 531 Mbit/s link. 


6.2.3.1 Operation of the OFC system 


During normal operation the optical link is a 
closed system and therefore clearly Class 1 
regardless of the power in the fibre. It is only 
when the link is opened that a person can be 
exposed to laser radiation; hence by imple- 
menting a safety interlock that can detect when 
the optical link has been disrupted and shut 
down the laser or reduce the optical power level, 
one can design a Class 1 system. A _ block 
diagram showing a basic optical link with OFC 
circuitry is shown in Figure 20 and will be used 
in the following description of the operation. 


The sequence of events which follow a discon- 
nection in the optical data link are as follows: 


1. Suppose data link A to B (1) is disconnected 
(for example, an opened connector or cut 
fibre). 
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(1) 


Optical 
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(A to B) 


Receiver and 
Amplifier 


Transmitter 
and Driver 


Control Circuitry 
and Timer 


Control Circuitry 
and Timer 


Transmitter Data 
and Driver +<—____—— 
(in) 


(4) 


Receiver and 
Amplifier 


(5) 


Optical 
Fibre 
(B to A) 


oe 


—————*] Port A) 


(Optical Port B) 


Figure 20. Block diagram of the OFC safety system 


. The receiver on optical port B (2) is no 
longer receiving an optical signal and trig- 
gers a loss-of-light flag to be raised in the 
-control circuitry (3) on port B. 


. The control circuitry (3) responds by forcing 
off the port B transmitter (4) and starting an 
internal T second timer. 


. Since the port B transmitter is now off, no 


optical signal is received by the port A. 


receiver (6). This triggers a loss-of-light flag 
to be raised in the control circuitry (7) on 
port A. 


. The control circuitry (7) responds by forcing 
off the port A transmitter (8) and starting an 
internal T second timer. Thus a safe condi- 
tion with respect to the opened end of the 
link (1) has been created since both trans- 
mitters are now Off. 


. When the internal T second timers expire, 
the control circuitry on each port will turn on 
the port’s transmitter for t microseconds to 
check the link status (i.e. check for a closed 
link). 


. If the link is now a closed loop (i.e. data link 
A to B.(1) has been reconnected), then a 
reconnect handshake’ will take place 
between the two ports and the transmitters 
will return to normal operation. If the link is 


still open, no optical signal will be received 
by at least one of the two receivers, the 
reconnect handshake will fail and the trans- 
mitters will once again be forced off for T 
seconds before the link check is repeated. 


8. Note that to allow for synchronization of the 
control circuitry on the two ports during the 
link status check and reconnect handshake, 
either the expiring of the port’s internal timer 
or the receiving of an optical signal from the 
other port causes an attempt to reconnect 
and the port timer to be reset. 


9. If both data links A to B (1) and B to A (5) 
are disconnected at the same time, both 
ports A and B independently turn off their 
transmitters since a loss-of-light signal is 
generated at each receiver. Normal opera- 
tion can not return until both data links are 
reconnected and the proper reconnect hand- 
shake has taken place between the ports. 


Turning the transmitters on briefly after a prede- 
termined time period T, allows the system to 
return to a normal mode of operation after an 
accidental or purposeful 
disconnection/reconnection of one or more of 
the connectors. Hence, the timed link checking 
and reconnection make the OFC safety interlock 
system automatic and nearly transparent to the 
user. 
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6.2.4 Link reconnection and OFC time 


periods 


During system start-up or link reconnection, a 
handshaking takes place between the two optical 
ports. This handshaking occurs after a closed 
link condition is detected and insures that both 
optical ports contain functioning safety control 
circuitry and are capable of shutting down in the 
event of a break in the link. If either port in the 
link (for example port B) does not respond to the 
handshaking, then the control circuitry at the 
other end of the link (port A) will keep its trans- 
mitter inactive (i.e. either no emission or brief 
pulses every T seconds) and thereby maintain a 
safe link. Hence, the electronic safety control 
functions as a safety interlock which can not be 
defeated by attaching an optical port without 
OFC safety control circuitry. 


The reconnection procedure is implemented with 
an on-off-on algorithm and _ four-state state 
machine as follows: 


1. The OFC sytem is in the Active state during 
normal operation. In this state, the receiver 
is continuously monitored for a loss-of-light 
(LOL) condition. If a LOL condition is 
detected (LOL high), the OFC system trans- 
fers control to the Disconnect state. 


2. The Disconnect state is used to maintain a 
safe (Class 1) link and to repetitively check 
the link for a closed link condition. Every T 
seconds the transmitter is activated for D1=t 
microseconds and the receiver is monitored 
for the LOL condition to disappear (LOL low). 
To exit from this state and proceed to the 
Stop state, light must be both sent and 
received during a t microsecond check 
period. This can occur in two ways: 


A. The T second timer expires, the trans- 
mitter is activated for D1=t microsec- 
onds and during this t microsecond 
period, a response is received from the 
other end of the link (i.e. LOL goes low). 
The transceiver is then considered 
“master” of the reconnection attempt. 
(NOTE: Due to timing variations, it is 
possible for both ends of the link to be 

“master” at the same time; this will not 

_ interfere with proper functioning of the 
OFC system.) 


B. A light signal is received from the other 
end of the link sometime during the T 
second wait period (i.e. LOL goes low). 
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The T second timer is reset and the 
transmitter activated for D1=t microsec- 
onds in order to send a response. In this 
situation, the transceiver is considered 
“slave” of the reconnection attempt. 


3. The Stop state is the “off” portion of the 


handshake algorithm. In the Stop state, the 
transmitter is disabled for D2 microseconds 
and the link monitored for a LOL condition 
(LOL high). The OFC system will remain in 
the Stop state until a LOL condition exists, 
this could be for an indefinite period of time. 
The system will exit from the Stop state in 
one of two ways: 


A. lf the LOL condition (LOL high) is 
detected within the D2 microsecond time 
period, then the OFC system will transfer 
control to the Reconnect state. 


B. If the LOL condition (LOL high) is 
detected after the D2 microsecond time 
period has expired, then control is 
passed back to the Disconnect state. 


4. The Reconnect state verifies that a closed 


link exists by requiring once again that light 
be sent and received during a D3=t micro- 
second time period. The behavior of this 
state is different depending upon 
whether-or-not the transceiver is “master” or 
“slave” of the reconnection attempt. 


A. If the transceiver is “master” of the 
reconnection attempt, then it once again 
initiates the send/receive sequence by 
activating its transmitter for D3=t micro- 
seconds and monitoring its receiver for a 
response signal (LOL low). If it receives 
a response within the t microsecond time 
period, it keeps the transmitter activated 
and transfers control to the Active state; 
otherwise, it disables the transmitter and 
transfers control back to the Disconnect 
state. 


B. If the transceiver is “slave” of the recon- 
nection attempt, then it monitors its 
receiver for D3=t microseconds for a 
light present signal (LOL low) but does 
not activate its transmitter. If it receives 
a light present signal within the t micro- 
second time period, it activates its trans- 
mitter in order to send a response and 
transfers control to the Active state; oth- 
erwise, it keeps its transmitter disabled 
and transfers control back to the Discon- 
nect state. 


The timing periods used during each of the 
states of the state machine depend upon the 
time lags in the control circuitry of the 
transceivers and the optical link length. One 
must wait a minimum of one worst case round 
trip time for a response. For more detailed 
information on a recommended implementation 
of the OFC system and state machine, refer to 
Annex H. 


6.2.4.1 OFC time periods 


The OFC system makes use of a repetitive 
pulsing technique (t microseconds on every T 
seconds) during the time that a link is open (i.e. 
in the Disconnect state) instead of continuous 
operation in order to reduce the maximum pos- 
sible viewing exposure to laser radiation and 
allow for classification as a Class 1 laser 
product. The maximum power level per pulse is 
a function of the wavelength, pulse duration (t), 
and pulse repetition frequency (PRF = 1/T) 
which determines the number of pulses (N) that 
occur during the time base used for classifica- 
tion purposes. Note that the use of the word 
“pulse” above refers to the "on time” during 
which the laser is powered on and being modu- 
lated with a valid full rate data pattern. The 
worst case maximum transmitter receptacle 
power allowed for the SW laser system is 


Transmitter receptacle (max) = 2,3 dBm (1,7 
mW). 


To function correctly, each SW optical data link 
port must contain a transceiver that has imple- 
mented the OFC system with compatible OFC 
interface timings. The timing values referred to 
above that are consistent with the assumed 
maximum transmitter receptacle power and 
current (1990) IEC laser safety restrictions for a 
Class 1 system are as follows: 
1. Pulse repetition time, T, (Disconnect state) 

— maximum = 11,9 seconds 
— minimum = 11,7 seconds 


2. Pulse duration, D1=D3=t, (Disconnect and 
Reconnect states) 


— maximum = 410 microseconds 
— minimum = 400 microseconds 
3. D2 stop time (Stop state) 


— maximum = 1 260 microseconds 
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— minimum = 1 250 microseconds 


These time periods when used according to the 
OFC interface specification described in this 
section, should result in a laser product which 
conforms to current (1990) emission require- 
ments for Class 1 classification world wide. 
Note, however, that classification of a laser 
product must always be verified with measure- 
ments and calculations and not assumed. 


6.2.5 Safety redundancy 


The safety standards require that the maximum 
permissible exposure level for Class 1 operation 
can not be exceeded under any condition of 
operation, including single fault conditions. One 
way to handle this requirement is to introduce 
redundancy into the OFC system. The OFC 
system described above is implemented using 
totally redundant paths. Each of the paths can 
independently turn off the laser and only when 
they agree to turn on the laser will the laser 
receive any power. Hence, a double fault is 
required in the control system before an unsafe 
situation can occur. 


The bloc diagram of the OFC system shown in 
figure 21 shows two control paths that must be 
satisfied before the laser can be activated. Each 
path contains a_ loss-of-light detector, digital 
filter, state machine, timers (counters) and laser 
driver control line. The two loss-of-light detec- 
tors monitor the receiver’s signal. At least one 
of the detectors must be AC coupled and there- 
fore respond only to a modulated signal. 


The two loss-of-light detectors each feed a 
digital filter, the output of each filter is 
‘OR/EQUAL’d to form an internal Loss-of-Light 
(LOL) signal. The two filter outputs must be 
‘EQUAL’ during the Disconnect, Stop and Recon- 
nect states to activate the laser and bring the 
link up to a normal operating mode. But once 
the system is in the Active state, the ‘OR’ is 
implemented so that only one light detector is 
required to bring the link down and deactivate 
the laser. 


The digital filters integrate the incoming signals 
to improve their reliability. The filters sample at 
a faster rate when acquiring a light present 
signal and at a slower rate when dropping a 
light present signal (i.e. setting LOL high), while 
still maintaining the correct handshake timings. 
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Figure 21. Block diagram of the OFC safety redundancy 


The internal LOL signals are used to synchro- 
nize the counters and state machines. The state 
machines control the handshake algorithm 
implemented in the OFC system. Each state 
machine controls a ‘Laser Off’ output that con- 
nects to separate laser drive control circuits. 
The counters control the pulse repetition, pulse 
duration and stop times. The counters also 
provide the low frequency sampling clock to the 
digital filters. 


6.3 25 MB/s MM 1 km LED data link 


6.3.1 Optical output interface 


The Active Output interface shall exhibit the 
characteristics as shown in table 6. 


6.3.2 Spectral width 


The spectral width is a function of source center 
wavelength and source rise and fall times. 
These specifications in conjunction with the 
fibre’s chromatic dispersion and modal band- 
width parameters given in section 7 result in an 
optical rise time of less than 3 ns exiting a 1 
kilometer fibre cable. Figure 22 shows curves 
for source rise and fall times ranging from 2,0 to 
2,0 Ns. 
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Figure 22. LED spectral width. 


6.3.3 Optical input interface 


The Active Input Interface shall operate when 
provided with a signal corresponding to table 6. 


6.4 12,5 MB/s 1 300nm MM LED 
500m data link 


6.4.1 Optical output interface 


The Active Output interface shall exhibit the 
characteristics as shown in table 6. 


6.4.2 Optical input interface 


The Active Input Interface shall operate when 
provided with a signal corresponding to table 6. 
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7 Coaxial cable interface specification | 


This clause defines the interfaces of the serial 
electrical signal at the interconnect receptacles. 
Each conforming FC attachment shall be compat- 
ible with this serial electrical interface to allow 
interoperability within an FC environment. The 
parameters specified in this clause are based on 


| 
| 
| 


a requirement that the bit error rate (BER) < 
10-12 be maintained under all conditions of 
section 7, including the minimum active input 
interface power level. The corresponding cable 
plant specifications are described in section 9. 


Table 8. FC-0 coaxial links 


FC-0 100-CX-TV-S 50-CX-TV-S 25-CX-TV-S 12-CX-TV-S 
100-CX-MI-S 50-CX-MI-S 25-CX-MI-S 12-CX-MI-S 
CELA AEE STEN HLL SERA RM DSS HOT 


Data Rate 
Nominal Bit Rate 
Tolerance 


MB/sec 
MBit/s 


100 


100 
Operating Range (typ) 
Cable type 


Transmitter(S) 


Type 

Output Voltage 
- maximum 

- minimum 


Ss 
14 (750) 


Duty Cycle Distortion (p-p) 
Random Jitter (p-p) 

Data Dependent Jitter (p-p) 
Rise/Fall Time (20-80%) 


Mask of Eye Diagram 


Min Sensitivity 

Min Overload 

Max AC path penalty 
AC frequency 

S 

14 (75Q) 


Min Discrete Conn. 
Return Loss 


7.1 Coaxial ECL data links 


The coaxial ECL data link definitions apply to two 
styles of coaxial cable, the 75 Q CATV style coax 
and miniature coaxial cable. The electrical char- 
acteristics of these links are defined in table 8. 
The 75 Q CATV style coax and miniature coaxial 
cables are interoperable, i.e., electrically com- 
patible with minor impact on link length capa- 
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1062,5 


10m/50m 


50 29 

531,25 265,625 
100 100 
10m/50m 10m/50m 


12,5 
132,813 
100 
10m/50m 


bility when intermixed. The interoperability 
implies that the transmitter and receiver level 
specifications defined in table 8 are preserved 
with the trade-off being distance capability in an 
intermixed system. Other electrically compat- 
ible, interoperable coaxial cables may be used 
to achieve goals of longer distance, higher fre- 
quency, or lower cost as desired in the system 


implementation provided that they are connector 


compatible. 
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Figure 23. FC-0 with CATV style coaxial cable 


7.2 75 © CATV style coaxial data 
link 


This coaxial ECL data link definition applies to 75 
Q CATV style cable with industry standard 75 Q 
BNC type connectors as shown in figure 23. The 
electrical performance of these 75Q BNC con- 
nectors is compatible with CATV style connec- 
tors specified by EIA-403-A. The mechanical 
compatibility is defined by MIL-C 39012 for this 
bayonet lock coupling connector which _ inter- 
mates with comparable BNC UG/U connectors. 
Primary use of these links is for interconnection 
of cabinets. 


7.2.1 ECL compatible driver 
characteristics 


The output driver is assumed to have Emitter 
Coupled Logic (ECL) output levels. Due to the 
AC coupled drive configuration (figure 23), this 
driver may be either negative voltage referenced 
ECL or positive voltage referenced ECL (PECL). 
The output driver shall have output levels, meas- 
ured at the input to the coax (point S), as shown 
in table 8, when terminated as shown in figure 
23. 


7.2.2 ECL compatible receiver 
characteristics 


The normalized mask of the transmitter eye 
diagram is given in figure 24. The transmitter 
output, as specified in table 9, shall be meas- 
ured using 50 m of cable (e.g. type RG-6/U from 
table 64 of annex Annex E) in the configuration 
shown in figure 23. The series terminating 


resistor (in figure 23) will cause a loss of 6 dB at 
the receiver and enough gain must be provided 
to minimize edge recovery losses. 


The equalizer network corrects for timing loss 
variations due to the differences in propagation 
delay time between higher frequency compo- 
nents as well as attenuation loss of the trans- 
mitted signal. A proper equalizer design will 
have fixed values and need no adjustment rela- 
tive to coaxial line length or levels. 


A more detailed discussion of the equalizer is 
found in section 7.4. 


Normalized Amplitude 


1-x2 1-x!1 
Normalized Time 


Figure 24. Eye Diagram 
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Table 9. CATV eye diagram m 
1 
0,15 0,35 


Lae 1 fae 


7.2.3 Coaxial cable characteristics 


The CATV style coaxial cables defined for this 
interface have characteristics defined in table 10. 


Table 10. Char of 75 Q, CATV coax 
Category Impedance Attenuation 
(nom.) 
Electrical 75+5 12dB/50m 
@531 MHz 


7.3 75 ( miniature coaxial data link 


This ECL data link is a 75 Q miniature coax with 
a optional shielded connector (figure 25) that 
interfaces with industry standard headers with 
0,64 mm (0,025 in) square posts on 2.54 mm 
(0,100 in) spacing. Primary use of these links is 
within a cabinet. 


Due to cost reasons, these connectors are not 
entirely shielded and leakage of RFI will occur. A 


shielded cabinet and leakage control techniques 


such as ferrite beads will be required to suc- 


cessfully meet EMC standards even with double 


shielded miniature coax (refer to annex E.4). 


7.3.1 ECL compatible driver 
characteristics 


The output driver is assumed to have Emitter 
Coupled Logic (ECL) output levels. Due to the 
AC coupled drive configuration (figure 25), this 
driver may be either negative voltage referenced 
ECL or positive voltage referenced ECL (PECL) 
levels. The output driver shall have output 
levels, measured at the input to the coax (point 
S), as shown in table 8, when terminated as 
shown in figure 25. 


7.3.1.1 ECL compatible receiver characteristics 


The normalized mask of the transmitter eye 
diagram is given in figure 24. The transmitter 
output, as specified in table 11, shall be meas- 
ured using 10 m of cable (e.g. type RG-179 B/U 
from table 66 of annex Annex E) in the config- 
uration shown in figure 25. The series termi- 
nating resistor (in figure 25) will cause a loss of 
6 dB at the receiver and enough gain must be 
provided to minimize edge recovery losses. 


Table 11. miniature coax eye diagram mask 
_ oe 721 " 


length 
om 
| 10m 


[ser mbive | 030 | 04s | a26 | 10m 
[tose wave | 030 | 04s [026 [10m 


The equalizer for the miniature 75Q coax is a 
design option for lower data rates and, in most 


Figure 25. FC-0 with miniature coaxial cable 


38 


Oa A ee 


cases, is probably not required for adequate 
error rate. As in the case of the CATV style 
coaxial data link described in section 7.2, the 
purpose of this equalizer is to compensate for 
propagation time variations between high fre- 
quency and lower frequency components of the 
transmitted signal. A proper equalizer design 
will have fixed values and need no adjustment 
relative to line length or levels. 


7.3.2 Miniature coaxial cable 
characteristics 


The miniature style coaxial cables defined for 
this interface have characteristics defined in 
table 12. 


It should be noted that the attenuation of the 
miniature coax at 531 MHz is less than the CATV 
coax characteristics specified in table 10. The 
miniature coax, by virtue of its smaller physical 
size, is more lossy to high frequency compo- 
nents of the signal than the CATV style cable. 
Therefore, the length and attenuation character- 
istics have been deliberately compromised to 
result in nearly the same signal levels and char- 
acteristics at the receiver that would be seen 
with CATV style cable. 


Table 12. Char of 75 Q, miniature coax 


Category Impedance Attenuation 
(nom.) 
| Electrical 75+5 OQ 


10dB/10m 
7.4 Equalizer network 


@531 MHz 


The equalizer network shown by block diagram 
in figures 23 and 25 corrects for timing loss due 
to the differences in propagation delay time 
between higher frequency components of the 
transmitted signal and amplitude loss at higher 
data rates. The primary physical mechanism of 
the loss is the skin effect characteristics of the 
coaxial cable. Except for these losses, the 
coaxial cable is extremely phase linear and very 
predictable for attenuation loss. 


The equalizer network needed for coaxial data 
link compensation should be designed to peak 
up the 1F (highest nominal data rate, e.g. 531 
MHz for 100 MB/sec transfers) and to accom- 
plish a linear phase delay of the lower frequen- 
cies to adjust the phase. An example of an 
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equalizer for a 25 MB/sec (132.813 MHz on the 
coax) is shown in figure 26 and 13. This 
equalizer attenuates the low frequency (=34 
MHz) by approximately 1 dB while also delaying 
the lower frequency components as much as 
0,12 ns. Attempting to compensate for the 3rd 
and 5th order harmonics of the digital signal into 
the coaxial cable is usually not profitable in that 
it results in a= fairly elaborate and _ costly 
equalizer. 


For lower data rates, one may make the eco- 
nomic trade-off of elimination of the equalizer at 
modest risk to error rate performance. At higher 
data rates, > 50 MB/sec, an equalizer is judged 
to be almost mandatory unless the cable length 
is short. | 


Table 13. Equalizer design example 


-0,9625 
-0,6845 
-0,5205 


-0,4067 


0,113 
0,191 


il 


M 
0 
0 


7 0,179 
0,156 


0,135 


-0,3255 
-0,2660 


0,100 
0,087 
0,076 
0,066 


cma, 


Hz 
20 
30 


ij 


238.142 pF 


26.867 Ohms 


75 Ohms 


209.2 Ohms 


1339.56 nH 


Figure 26. Equalizer design example 
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8 Fibre cable plant specification 


The term “cable plant” encompasses all the fibre 
optic components between any two communi- 
cating ports and the associated connector plug 
at each end of the link. 


8.1 SM cable plant specification 


This sub-section specifies a single mode cable 
plant which is capable of supporting communi- 
cation at distances of 2 and 10 Km at data rates 
of 265,625 MBit/s, 531,25 MBit/s and 1,062 5 
GBit/s and provides for system upgrade. The 
cable plant is generally insensitive to data rate 
and therefore any installed portions of the cable 
plant may be used at any data rate. (See table 
14.) 


Table 14. Single mode cable plant 


FC-0 100-} 100-} 50- 
SM-| SM- 
LL-L} LL-I 


SM- 
6 | 6. 


LL-L 


9. . 


Dispersion 


Dispersion 
Related 


Penalty 


Reflection 
Related 
Penalty 


8.1.1 Fibre type 


The fibre shall conform to EIA/TIA 492BAAA, 
"Detail Specification for Class IVa Dispersion 
Unshifted Single Mode Optical Waveguide Fibers 
Used In Communications Systems”. 
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8.1.2 Cable plant loss budget 


The loss budget for single mode fibre shall be no 
greater than specified in table 14. These limits 
were arrived at by taking the difference between 
the minimum transmitter output power and the 
receiver sensitivity and subtracting 2 dB to 
account for the dispersion and reflection link 
penalties. See annex D.3 for cable plant exam- 
ples. 


The cable plant loss shall be verified by the 
methods of FOTP-171, Method B3 or C3. 


There are no requirements for fixed attenuators 
in the single mode classes. All receivers and 
transmitters, of a given data rate, may intercom- 
municate without operability limit as long as the 
distance requirement of the shorter class is not 
exceeded. 


8.1.3 Optical return loss 


The cable plant optical return loss, with the 
receiver connected shall be greater than or 
equal to 12 dB. This is required to keep the 
reflection penalty under control. The receiver 
shall have a return loss greater than or equal to. 
one glass air interface, hence equivalent to the 
termination of the cable plant. 


Mid-link connectors and splices are required to 
have a return loss greater than 30dB in order to 
control interferometric noise. 


8.2 MM 62,5 um Cable plant 
specification 


The 62,5 wm Cable plant is the preferred cable 
plant for the 1 300nm LED based components. 
The short wave length 780nm CD laser can also 
be used on the 62,5 wm cable plant with some 
limited distance restrictions. See Annex B and 
Annex D. 


Table 15. 62,5 wm multi-mode cable plant 


12-M6- 
LE-| 


8.2.1 Fibre types 


The fibre shall conform to EIA/TIA - 492AAAA, 
"Detail Specification for 62,5 wm Core 
Diameter/125 ym Clading Diameter Class 1a 
Multimode, Graded Index Optical Waveguide 
Fibres”. 


Table 16. 62,5 um fibre type 


Nominal Core Cladding Nominal 
Diameter Diameter Numerical 
EIA-455-58 EIA-455-45 & Aperture 
EIA-455-176 EIA-455-177 
or 
EIA-455-48 


8.2.2 Bandwidth 


The following normalized bandwidth values are 
based on a nominal source wavelength of 850 
and 1 300 nm. (See table 17.) 


Table 17. 62,5 44m multi-mode bandwidth 


Modal band- 
width — 


Wavelength Test per 


(-3dB optical 
min) 


EIA-455-30 or 
EIA-455-51 
with 
EIA-455-54 


EIA-455-30 or 
EIA-455-51 
with 
EIA-455-54 


_ 
1 300nm 500MHz*km 


NOTE - Some users may wish to install higher 
modal bandwidth fibre to facilitate later future 
use of the cable plant for higher bandwidth 
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applications. For shorter distances, a lower 
bandwidth fibre may be substituted provided the 
performance requirements are met. 


8.2.3 Cable plant loss budget 


The loss budget for the multi-mode fibre cable 
plant shall be no greater than specified in table 
15. These limits were arrived at by taking the 
difference between the minimum. transmitter 
output power and the receiver sensitivity. This 
includes the losses of the fiber and other compo- 
nents in the link such as splices and connectors. 
The connectors at the ends of the links are 
included in the transmitter and receiver specifi- 
cations and not in the cable plant limit. 


In some cases the modal dispersion limit may 
be reached in an installaton before the installa- 
tion loss limit of table 15. See annex D.4 for 
examples. 


Conformace to the loss budget requirements 
shall be verified by means of OFSTP-14. 


8.2.4 Fibre chromatic dispersion 
parameters 


oS oS = = a) 
[me | [ one ] aomndin —* as 
S oS 3 oS oS 
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i | 
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| 
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1280 


1300 
ZERO DISPERSION WAVELENGTH (nm) 


1320 1540 1560 


Figure 27. Fiber chromatic dispersion parame- 
fers 
Figure 27 illustrates the required zero dispersion 


wavelength and the dispersion slope values for 
multimode fibre. 


41 


FC-PH REV 2.1, May 25, 1991 


Sufficient optical bandwidth is provided when the 
zero dispersion wavelength and the dispersion 
slope measured at the zero dispersion wave- 
length (as defined by EIA-455-168) fall within the 
highlighted area. 


These modal bandwidth and _— chromatic 
dispersion requirements in conjunction with the 
specifications on the center wavelength, spectral 
width, and risetimes of the transmitter in the 
active output interface specification in section 6 
assures a 3 ns. exit response time over the 
respective distance. 


8.3 MM 50 ym cable plant 
specification 


The 50 wm cable plant is the preferred cable 
plant for the 780nm short wave length CD laser. 
The long wave length 1 300nm LED based com- 
ponents may also be used on the 50 wm cable 
plant with some distance restrictions. See 
annexes Annex B and Annex D. 


Table 18. 50 44m multi-mode cable plant 


FC-0 50-M5- 25-M5- 
SL-I SL-I 
=p 


Operating 
Range 


Loss Budget 


8.3.1 Fibre type 


The 50yum fibre shall meet the requirements in 
tables 18, 19, and 20. 


Table 19. 50 ym fibre type 


Nominal 
Numerical 
Aperture 


Nominal Core 
Diameter 
EIA-455-58 


Cladding 
Diameter 
EIA-455-45 & 
EIA-455-176 
or 
EIA-455-48 


EIA-455-177 
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8.3.2 Bandwidth 


The following normalized bandwidth values are 
based on a nominal source wavelength of 850 
and 1 300 nm. (See table 20.) 


Table 20. 50 4m multi-mode bandwidth 


Modal band- 
width 


Test per 


(-3dB optical 


Wavelength 
min) 
_ 
1 300nm 500MHz*km 


Note: The bandwidth shown in the table will 
meet the performance requirements for 780 nm 
laser operation. 


EIA-455-30 or 
EIA-455-51 
with 
EIA-455-54 


EIA-455-30 or 
EIA-455-51 
with 
EIA-455-54 


8.3.3 Cable plant loss budget 


The loss budget for the 504m multi-mode fibre 
cable plant shall be no greater than specified in 
table 18. These limits were arrived at by taking 
the difference between the minimum transmitter 
output power and the receiver sensitivity. This 
includes the losses of the fiber and other compo- 
nents in the link such as splices and connectors. 
The connectors at the ends of the links are 
included in the transmitter and receiver specifi- 
cations and not in the cable plant limit. 


In some cases the modal dispersion limit may 
be reached in an installaton before the installa- 
tion loss limit of table 18. See annex D4 for 
examples. 


The loss of the cable plant shall be verified by 
the methods of OFSTP-14. 


8.3.4 Fibre chromatic dispersion 
parameters 


The effects of chromatic dispersion on system 
bandwidth are illustrated in figure 27. 


Sufficient optical bandwidth is provided when the 
optical transmitter center wavelength and spec- 
tral width are as specified in table 6. 


These modal bandwidth and_— chromatic 
dispersion requirements in conjunction with the 
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specifications on the center wavelength, spectral 
width and risetimes of the transmitter in the 
active output interface specification in section 6 


assures a 3 ns exit response time over the 


respective distance. 


8.4 Connectors and splices 


Connectors and splices of any nature are 
allowed inside the cable plant. The number and 
quality of connections affect the loss of the cable 
plant and represent a design trade-off outside 
the scope of the standard. 
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9 Coaxial cable plant specification 


This section defines the link requirements for an 


FC coaxial cable plant. The term “cable plant” 
encompasses all the components between any 
two communicating ports and the associated 
connector plug at each end of the link. 


Performance to this standard shall be met by 
meeting the data link characteristics defined in 
table 8 of section 7, the coaxial cable interface 
specification. A specific goal of the coaxial cable 
plant is to allow interoperability with restricted 
lengths of miniature coax cable and CATV style 
coax. For example, as long as the miniature 
coax cable is less than 2 m in length for both 
cabinets, the full 50 m capability of the CATV 
style coax should be achievable for cabinet 
interconnections. 
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Especially at data rates 50 MB/sec or greater, 
particular attention must be given to the transi- 
tion board that changes signals from miniature 
coax to the BNC coaxial connector for the CATV 
style coax. No more than four miniature coaxial 
connectors should be present from the ECL 
transmitter to the receiver of the data link. 


Careful attention to details as noted above will 
allow the system designer to construct a low- 
cost and yet high performance system capable 
of reliable error rate performance, The coaxial 
data link will meet the requirements of many 
shorter distance Fiber Channel applications. 


American National Standard 
for Information Systems 


FC-PH REV 2.1, May 25, 1991 


FC-1 level - Transmission protocol 


10 8B/10B Transmission Code 


Information to be transmitted over a Fibre shall 
be encoded eight bits at a time into a 10-bit 
Transmission Character and then sent serially 
by bit. Information received over a Fibre shall 
be collected ten bits at a time, and those Trans- 
mission Characters that are used for data, called 
Data Characters, are decoded into the correct 
eight-bit codes. The 10-bit Transmission Code 
supports all 256 eight-bit combinations. Some of 
the remaining Transmission Characters, referred 
to as Special Characters, are used for functions 
which are to be distinguishable from the con- 
tents of a frame. 


NOTE - The primary rationale for use of a Trans- 
mission Code is to improve the transmission 
characteristics of information to be transferred 
across a Fibre. The Encodings defined by the 
Transmission Code ensure that sufficient transi- 
tions are present in the serial bit stream to make 
clock recovery possible at the Receiver. Such 
Encoding also greatly increases the likelihood of 
detecting any single or multiple bit errors that 
may occur during transmission and reception of 
information. In addition, some of the Special 
Characters of the Transmission Code contain a 
distinct and easily recognizable bit pattern (a 
Comma) which assists a Receiver in achieving 
word alignment on the incoming bit stream. 


10.1 Notation conventions 


FC-1 uses letter notation for the bits of an 
eight-bit byte. Such notation differs from the bit 
notation specified by the remainder of this 
standard (see 3.2). The following text describes 
the translation process between these notations 
and provides a translation example. It also 
describes the conventions used to name valid 
Transmission Characters. 


The bit notation of A,B,C,D,E,F,G,H is used for an 
eight-bit byte. The bits A,B,C,D,E,F,G,H are 
translated to bits a,b,c,d,e,i,f,g,h,j of 10-bit Trans- 
mission Characters. There is a correspondence 
between bit A and bit a, B and b, C andc, D and 
d, E and e, F and f, G and g, and H and h. Bits ij 
and j are derived, respectively, from (A,B,C,D,E) 
and (F,G,H). 


The bit labeled A corresponds to bit O in the 
numbering scheme of the FC-2 specification, B 
corresponds to bit 1, as shown in figure 28. 


FC-2 bit 

designation—> 76543210 
8B/10B bit 

designation—> HGFEDCBA 


Figure 28. Bit designations 
Figure 29 shows the conversion from an FC-2 


Valid Data Byte to a Transmission Character 
(using 8B/10B Transmission-Code notation). 
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FC-2 byte notation: 


Hex 45 
Bits: 7654 3210 


Are. REE 


0100 0101 


Converted to 8B/10B notation 
(note carefully that the order of 
bits is reversed): 


Bits: ABCDE FGH 


TE | EC 


10100 010 
Translated to a 10-bit Transmission Character: 
Bits: abcdei fghj 


reer 


101001 0101 


Figure 29. Conversion example 


Each valid Transmission Character has been 
given a name using the following convention: 
zxx.y, where z is used to indicate whether the 
Transmission Character is a Data Character (z 
= D) or a Special Character (z = K). When z 
= D, xx is the decimal value of the binary 
number composed of the bits E, D, C, B, and Ain 
that order, and y is the decimal value of the 
binary number composed of the bits H, G, and F 
in that order. When z = K, xx and y are derived 
by comparing the encoded bit patterns of the 
Special Character to those patterns derived from 
encoded Valid Data Bytes and selecting the 
names of the patterns most similar to the 
encoded bit patterns of the Special Character. 


Under the above conventions, the Transmission 
Character in figure 29 is referred to by the name 
D5.2. The Special Character K29.7 is so named 
because the first six bits (abcdei) of this char- 
acter make up a bit pattern similar to that 
resulting from the Encoding of the unencoded 
11101 pattern (29), and because the second four 
bits (fghj) of this character make up a bit pattern 
similar to that resulting from the Encoding of the 
unencoded 111 pattern (7). 


NOTE - This definition of the 10-bit Transmission 


Code is based on (and is in basic agreement 
with) the following references. Both of these ref- 
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erences describe the same 10-bit transmission 
code. 


A. X. Widmer and P. A. Franaszek. “A 


DC-Balanced, Partitioned-Block, 8B/10B 
Transmission Code,” /BM Journal of 
Research and Development, 27, 


No. 5: 440-451 (September, 1983). 


U.S. Patent 4,486,739. Peter A. Franaszek 
and Albert X. Widmer. Byte Oriented DC 
Balanced (0,4) 8B/10B Partitioned Block 
Transmission Code (December 4, 1984). 


10.2 Encoding and Decoding 


The following information describes how the 
tables shall be used for both generating valid 
Transmission Characters (Encoding) and 
checking the validity of received Transmission 
Characters (Decoding). It also specifies the 
ordering rules to be followed when transmitting 
the bits within a character and the characters 
within the higher-level constructs specified by 
the document (i.e., Ordered Sets and frames). 


10.2.1 Transmission order 


Within the definition of the 8B/10B Transmission 
Code, the bit positions of the Transmission Char- 
acters are labeled a,b,c,d,e,i,f,g,h, and j. Bit “a” 
shall be transmitted first, followed by bits “b,” 
“ce,” “d,” “ee,” “i,” “Fg,” “h,,” and “j,” in 
that order. (Note that bit “i” shall be transmitted 
between bit “e” and bit “f,” rather than in the 
order that would be indicated by the letters of 
the alphabet.) 


Characters within Ordered Sets (as specified by 
10.3) shall be transmitted sequentially beginning 
with the Special Character used to distinguish 
the Ordered Set (e.g., K28.5) and proceeding 
character by character from left to right within 
the definition of the Ordered Set until all charac- 
ters of the Ordered Set are transmitted. 


The contents of a frame (as specified by FC-2 in 
17) shall be transmitted sequentially beginning 
with the Ordered Set used to denote the start of 
frame (the SOF delimiter) and proceeding char- 
acter by character from left to right within the 
definition of the frame until the Ordered Set used 
to denote the end of frame (the EOF delimiter) is 
transmitted. 


10.2.2 Valid and invalid Transmission 
Characters 


Tables 21 and 22 define the valid Data Charac- 
ters and valid Special Characters (K characters), 
respectively. The tables are used for both gen- 
erating valid Transmission Characters 
(Encoding) and checking the validity of received 
Transmission Characters (Decoding). In the 
tables, each Valid-Data-Byte or Special-Code 
entry has two columns that represent two (not 
necessarily different) Transmission Characters. 
The two columns correspond to the current 
value of the Running Disparity (“Current RD —” 
or “Current RD +”). Running Disparity is a 
binary parameter with either the value negative 
(—) or the value positive (+). 


After powering on, the Transmitter shall assume 
the negative value for its initial Running Dis- 
parity. Upon transmission of any Transmission 
Character, the Transmitter shall calculate a new 
value for its Running Disparity based on the con- 
tents of the transmitted character. 


After powering on, the Receiver may assume 
either the positive or negative value for its initial 
Running Disparity. Upon reception of any Trans- 
mission Character, the Receiver shall determine 
whether the Transmission Character is valid or 
invalid according to the following rules and 
tables and shall calculate a new value for its 
Running Disparity based on the contents of the 
received character. 


The following rules for Running Disparity shall 
be used to calculate the new Running Disparity 
value for Transmission Characters that have 
been transmitted (Transmitter’s Running Dis- 
parity) and that have been received (Receiver’s 
Running Disparity). 


Running Disparity for a Transmission Character 
shall be calculated on the basis of sub-blocks, 
where the first six bits (abcdei) form one sub- 
block (six-bit sub-block) and the second four bits 
(fghj) form the other sub-block (four-bit sub- 
block). Running Disparity at the beginning of the 
six-bit sub-block is the Running Disparity at the 
end of the last Transmission Character. Running 
Disparity at the beginning of the four-bit sub- 
block is the Running Disparity at the end of the 
six-bit sub-block. Running Disparity at the end 
of the Transmission Character is the Running 
Disparity at the end of the four-bit sub-block. 


FC-PH REV 2.1, May 25, 1991 


Running Disparity for the sub-blocks shall be cal- 
culated as follows: 


1. Running Disparity at the end of any sub- 
block is positive if the sub-block contains 
more ones than zeros. It is also positive at 
the end of the six-bit sub-block if the six-bit 
sub-block is 000111, and it is positive at the 
end of the four-bit sub-block if the four-bit 
sub-block is 0011. 


2. Running Disparity at the end of any sub- 
block is negative if the sub-block contains 
more zeros than ones. It is also negative at 
the end of the six-bit sub-block if the six-bit 
sub-block is 111000, and it is negative at the 
end of the four-bit sub-block if the four-bit 
sub-block is 1100. 


3. Otherwise, Running Disparity at the end of 
the sub-block is the same as at the begin- 
ning of the sub-block. 


10.2.2.1 Use of the tables for generating 
Transmission Characters 


The appropriate entry in the table shall be found 
for the Valid Data Byte or Special Code for which 
a Transmission Character is to be generated 
(encoded). The current value of the Transmit- 
ter’s Running Disparity shall be used to select 
the Transmission Character from its corre- 
sponding column. For each Transmission Char- 
acter transmitted, a new value of the Running 
Disparity shall be calculated. _ This new value 
shall be used as the Transmitter’s Current 
Running Disparity for the next Valid Data Byte or 
Special Code to be encoded and transmitted. 


10.2.2.2 Use of the tables for checking the 
validity of received Transmission Characters 


The column corresponding to the current value 
of the Receiver’s Running Disparity shall be 
searched for the received Transmission Char- 
acter. If the received Transmission Character is 
found in the proper column, then the Trans- 
mission Character shall be considered valid and 
the associated data byte or Special Code deter- 
mined (decoded). If the received Transmission 
Character is not found in that column, then the 
Transmission Character shall be considered 
invalid and a Code Violation detected. Inde- 
pendent of the Transmission Character’s validity, 
the received Transmission Character shall be 
used to calculate a new value of Running Dis- 
parity. This new value shall be used as the 
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Receiver’s Current Running Disparity for the 
next received Transmission Character. 


NOTE - Detection of a Code Violation does not 


necessarily indicate that the Transmission Char- 
acter in which the Code Violation was detected 


Character 


101010 1001 


101010 1011 


p= 010101 0101 


is in error. Code Violations may result from a 
prior error which altered the Running Disparity 
of the bit stream but which did not result in a 
detectable error at the Transmission Character 
in which the error occurred. The example 
shown in figure 30 exhibits this behavior: 


010101 0101 


Figure 30. Delayed Code Violation example 
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Table 21 (Page 1 of 3). Valid Data Characters 
Bits Byte Bits 
HGF EDCBA|  abcdei fghj abcde fghj Name| GF EDCBA)  abcdei fghj abcdei fghj 


000 00000 


100111 0100 


011000 1011 


001 10000 


011011 1001 


100100 1001 


000 00001 011101 0100 100010 1011 001 10001 100011 1001 100011 1001 
000 00010 101101 0100 010010 1011 001 10010 010011 1001 010011 1001 
000 00011 110001 1011 110001 0100 001 10011 110010 1001 110010 1001 
000 00100 110101 0100 001010 1011 001 10100 001011 1001 001011 1001 
000 00101 101001 1011 101001 0100 001 10101 101010 1001 101010 1001 
000 00110 011001 1011 011001 0100 001 10110 011010 1001 011010 1001 
000 00111 111000 1011 000111 0100 001 10111 111010 1001 000101 1001 
000 01000 111001 0100 000110 1011 001 11000 110011 1001 001100 1001 
000 01001 100101 1011 100101 0100 001 11001 100110 1001 100110 1001 
000 01010 010101 1011 010101 0100 001 11010 010110 1001 010110 1001 
000 01011 110100 1011 110100 0100 001 11011 110110 1001 001001 1001 
000 01100 001101 1011 001101 0100 001 11100 001110 1001 001110 1001 
000 01101 101100 1011 101100 0100 001 11101 101110 1001 010001 1001 
000 01110 011100 1011 011100 0100 001 11110 011110 1001 100001 1001 
000 01111 010111 0100 101000 1011 001 11111 101011 1001 010100 1001 
000 10000 011011 0100 100100 1011 010 00000 100111 0101 011000 0101 
000 10001 100011 1011 100011 0100 010 00001 011101 0101 100010 0101 
000 10010 010011 1011 010011 0100 010 00010 101101 0101 010010 0101 
000 10011 110010 1011 110010 0100 010 00011 110001 0101 110001 0101 
000 10100 001011 1011 001011 0100 010 00100 110101 0101 001010 0101 
000 10101 101010 1011 101010 0100 010 00101 101001 0101 101001 0101 
000 10110 011010 1011 011010 0100 010 00110 011001 0101 011001 0101 
000 10111 111010 0100 000101 1011 010 00111 111000 0101 000111 0101 
000 11000 110011 0100 001100 1011 010 01000 111001 0101 000110 0101 
000 11001 100110 1011 100110 0100 010 01001 100101 0101 100101 0101 
000 11010 010110 1011 010110 0100 010 01010 010101 0101 010101 0101 
000 11011 110110 0100 001001 1011 010 01011 110100 0101 110100 0101 
000 11100 001110 1011 001110 0100 010 01100 001101 0101 001101 0101 
000 11101 101110 0100 010001 1011 010 01101 101100 0101 101100 0101 
000 11110 011110 0100 100001 1011 010 01110 011100 0101 011100 0101 
000 11111 101011 0100 010100 1011 010 01111 010111 0101 101000 0101 
001 00000 100111 1001 011000 1001 010 10000 011011 0101 100100 0101 
001 00001 011101 1001 100010 1001 010 10001 100011 0101 100011 0101 
001 00010 101101 1001 010010 1001 010 10010 010011 0101 010011 0101 
001 00011 110001 1001 110001 1001 010 10011 110010 0101 110010 0101 
001 00100 110101 1001 001010 1001 010 10100 001011 0101 001011 0101 
001 00101 101001 1001 101001 1001 010 10101 101010 0101 101010 0101 
001 00110 011001 1001 011001 1001 010 10110 011010 0101 011010 0101 
001 00111 111000 1001 000111 1001 010 10111 111010 0101 000101 0101 
001 01000 111001 1001 000110 1001 010 11000 110011 0101 001100 0101 
001 01001 100101 1001 100101 1001 010 11001 100110 0101 100110 0101 
001 01010 010101 1001 010101 1001 010 11010 010110 0101 010110 0101 
001 01011 110100 1001 110100 1001 010 11011 110110 0101 001001 0101 
001 01100 001101 1001 001101 1001 010 11100 001110 0101 001110 0101 
001 01101 101100 1001 101100 1001 010 11101 101110 0101 010001 0101 
001 01110 011100 1001 011100 1001 010 11110 011110 0101 100001 0101 


001 01111 


010111 1001 


101000 1001 


010 11111 


101011 0101 


010100 0101 
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Table 21 (Page 2 of 3). Valid Data Characters | 
Bi Current RD- | Current RD +{| Data ; Current RD - Current RD + 
its Byte Bits 
HGF EDCBA|  abcdei fghj abcdei fghj Name| HGF EDCBA)  abcdei fghj abcdei fghj 


50 


011 00000 


100111 0011 


011000 1100 


100 10000 


011011 0010 


100100 1101 


011 00001 011101 0011 100010 1100 . 100 10001 100011 1101 100011 0010 
011 00010 101101 0011 010010 1100 100 10010 010011 1101 010011 0010 
011 00011 110001 1100 110001 0011 100 10011 110010 1101 110010 0010 
011 00100 110101 0011 001010 1100 100 10100 001011 1101 001011 0010 
011 00101 101001 1100 101001 0011 100 10101 101010 1101 101010 0010 
011 00110 011001 1100 011001 0011 100 10110 011010 1101 011010 0010 
011 00111 111000 1100 000111 0011 100 10111 111010 0010 000101 1101 
011 01000 111001 0011 000110 1100 100 11000 110011 0010 001100 1101 
011 01001 100101 1100 100101 0011 100 11001 100110 1101 100110 0010 
011 01010 010101 1100 010101 0011 100 11010 010110 1101 010110 0010 
011 01011 110100 1100 110100 0011 100 11011 110110 0010 001001 1101 
011 01100 001101 1100 001101 0011 100 11100 001110 1101 001110 0010 
011 01101 101100 1100 101100 0011 100 11101 101110 0010 010001 1101 
011 01110 011100 1100 011100 0011 100 11110 011110 0010 100001 1101 
011 01111 010111 0011 101000 1100 100 11111 101011 0010 010100 1101 
011 10000 011011 0011 100100 1100 101 00000 100111 1010 011000 1010 
011 10001 100011 1100 100011 0011 101 00001 011101 1010 100010 1010 
011 10010 010011 1100 010011 0011 101 00010 101101 1010 010010 1010 
011 10011 110010 1100 110010 0011 101 00011 110001 1010 110001 1010 
011 10100 001011 1100 001011 0011 101 00100 110101 1010 001010 1010 
011 10101 101010 1100 101010 0011 101 00101 101001 1010 101001 1010 
011 10110 011010 1100 011010 0011 101 00110 011001 1010 011001 1010 
011 10111 111010 0011 000101 1100 101 00111 111000 1010 |}. 000111 1010 
011 11000 110011 0011 001100 1100 101 01000 111001 1010 000110 1010 
011 11001 100110 1100 100110 0011 101 01001 100101 1010 100101 1010 
011 11010 010110 1100 010110 0011 101 01010 010101 1010 010101 1010 
011 11011 110110 0011 001001 1100 101 01011 110100 1010 110100 1010 
011 11100 001110 1100 001110 0011 101 01100 001101 1010 001101 1010 
011 11101 101110 0011 010001 1100 101 01101 101100 1010 101100 1010 
011 11110 011110 0011 100001 1100 101 01110 011100 1010 011100 1010 
O11 11111 101011 0011 010100 1100 101 01111 010111 1010 101000 1010 
100 00000 100111 0010 011000 1101 101 10000 011011 1010 100100 1010 
100 00001 011101 0010 100010 1101 101 10001 100011 1010 100011 1010 
100 00010 101101 0010 010010 1101 101 10010 010011 1010 010011 1010 
100 00011 110001 1101 110001 0010 101 10011 110010 1010 110010 1010 
100 00100 110101 0010 001010 1101 101 10100 001011 1010 001011 1010 
100 00101 101001 1101 101001 0010 101 10101 101010 1010 101010 1010 
100 00110 011001 1101 011001 0010 101 10110 011010 1010 011010 1010 
100 00111 111000 1101 000111 0010 101 10111 111010 1010 000101 1010 
100 01000 111001 0010 000110 1101 101 11000 110011 1010 001100 1010 
100 01001 100101 1101 100101 0010 101 11001 100110 1010 100110 1010 
100 01010 010101 1101 010101 0010 101 11010 010110 1010 010110 1010 
100 01011 110100 1104 110100 0010 101 11011 110110 1010 001001 1010 
100 01100 001101 1101 001101 0010. 101 11100 001110 1010 001110 1010 
100 01101 101100 1101 101100 0010 101 11101 101110 1010 010001 1010 
100 01110 011100 1101 011100 0010 101 11110 011110 1010 100001 1010 


100 01111 


010111 0010 


101000 1101 


101 11111 


101011 1010 


010100 1010 
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Table 21 (Page 3 of 3). Valid Data Characters 
; Current RD - Current RD +1]| Data Current RD - 
Bits Byte Bits 
HGF EDCBA! abcde fghj abcdei fghj Name HGF EDCBA| abcdei fghj abcdei fghj 


110 00000 100111 0110 011000 0110 111 00000 100111 0001 011000 1110 
110 00001 011101 0110 100010 0110 111 00001 011101 0001 100010 1110 
110 00010 101101 0110 010010 0110 111 00010 101101 0001 010010 1110 
110 00011 110001 0110 110001 0110 111 00011 110001 1110 110001 0001 
110 00100 110101 0110 001010 0110 111 00100 110101 0001 001010 1110 
110 00101 101001 0110 101001 0110 111 00101 101001 1110 101001 0001 
110 00110 011001 0110 011001 0110 111 00110 011001 1110 011001 0001 
110 00111 111000 0110 000111 0110 111 00111 111000 1110 000111 0001 
110 01000 111001 0110 000110 0110 111 01000 111001 0001 000110 1110 
110 01001 100101 0110 100101 0110 111 01001 100101 1110 100101 0001 
110 01010 010101 0110 010101 0110 111 01010 010101 1110 010101 0001 
110 01011 110100 0110 110100 0110 111 01011 110100 1110 110100 1000 
110 01100 001101 0110 001101 0110 111 01100 001101 1110 001101 0001 
110 01101 101100 0110 101100 0110 111 01101 101100 1110 101100 1000 
110 01110 011100 0110 011100 0110 111 01110 011100 1110 011100 1000 
110 01111 010111 0110 101000 0110 111 01111 010111 0001 101000 1110 
110 10000 011011 0110 100100 0110 111 10000 011011 0001 100100 1110 
110 10001 100011 0110 100011 0110 111 10001 100011 0111 100011 0001 
110 10010 010011 0110 010011 0110 111 10010 010011 0111 010011 0001 
110 10011 110010 0110 110010 0110 111 10011 110010 1110 110010 0001 
110 10100 001011 0110 001011 0110 111 10100 001011 0111 001011 0001 
110 10101 101010 0110 101010 0110 111 10101 101010 1110 101010 0001 
110 10110 011010 0110 011010 0110 111 10110 011010 1110 011010 0001 
110 10111 111010 0110 000101 0110 111 10111 111010 0001 000101 1110 
110 11000 110011 0110 001100 0110 111 11000 110011 0001 001100 1110 
110 11001 100110 0110 100110 0110 111 11001 100110 1110 100110 0001 
110 11010 010110 0110 010110 0110 111 11010 010110 1110 010110 0001 
110 11011 110110 0110 001001 0110 111 11011 110110 0001 001001 1110 
110 11100 001110 0110 001110 0110 111 11100 001110 1110 001110 0001 
110 11101 101110 0110 010001 0110 111 11101 101110 0001 010001 1110 
110 11110 011110 0110 100001 0110 111 11110 011110 0001 100001 1110 


110 11111 


101011 0110 


010100 0110 


111 11111 


101011 0001 


010100 1110 


Table 22. Valid Special Characters 


Special 
Code 
Name 


001111 0100 
001111 1001 
001111 0101 
001111 0011 
001111 0010 
001111 1010 
001111 0110 
001111 1000 
111010 1000 
110110 1000 
101110 1000 
011110 1000 


Explanation: 


abcdei fghj abcdei fghj 


110000 1011 
110000 0110 
110000 1010 
110000 1100 
110000 1101 
110000 0101 
110000 1001 
110000 0111 
000101 0111 
001001 0111 
010001 0111 
100001 0111 


Reserved 
Reserved 
Reserved 
Reserved 
Reserved 


Reserved 
Reserved 
Reserved 
Reserved 
Reserved 
Reserved 


Reserved - valid Transmission Characters 
which are not defined for use by this standard 


The K28.7 Special Character shall not be fol- 
lowed by any of the following Special or Data 
Characters: K28.x, D3.x, D11.x, D12.x, D19.x, 
D20.x, or D28.x, where x is a value in the range O 
to 7, inclusive. 


NOTE - The above restriction simplifies word 
synchronization hardware. 


10.3 Ordered Sets 


Tables 23, 24, and 25 specify the Ordered Sets 
(composed of Special and Data Characters) 
which are defined for use by this standard. The 
following Ordered Set types are defined by FC-2 
in 16: 


— Delimiter Functions 
— Primitive Signals 
— Primitive Sequences 
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oe Table 23. Delimiter Functions 


| : Delimiter Beginning 


SOF Connect Class 1 (SOFc1) 
SOF Initiate Class 1 (SOFi1) 
SOF Normal Class 1 (SOFn1/) 
SOF Initiate Class 2 (SOFi2) 
SOF Normal Class 2 (SOFn2) 
SOF Initiate Class 3 (SOFi3) 
SOF Normal Class 3 (SOFn3) 
SOF Fabric (SOFf) 


EOF Terminate (EOFt) 
EOF Disconnect-Terminate (EOFdt) 


EOF Abort (EOFa) 


EOF Normal (EOFn) 


EOF Disconnect-Terminate-Invalid (EOFdti) 


EOF Normal-Invalid (EOFni) 


Explanation: 


SOF - Start-of-frame delimiter 
EOF - End-of-frame delimiter 


Negative 
Negative 
Negative 
Negative 
Negative 
Negative 
Negative 
Negative 


Negative 
Positive 


Negative 
Positive 


Negative 
Positive 


Negative 
Positive 


Negative 
Positive 


Negative 
Positive 


K28.5 D21.5 


K28.5 D21.5 


K28.5 D21.5 


K28.5 D21.5 


K28.5 D21.5 


K28.5 D21.5 


K28.5 D21.5 


K28.5 D21.5 


K28.5 D21.4 
K28.5 D21.5 


K28.5 D21.4 
K28.5 D21.5 


K28.5 D21.4 
K28.5 D21.5 


K28.5 D21.4 
K28.5 D21.5 


K28.5 D10.4 
K28.5 D10.5 


K28.5 D10.4 
K28.5 D10.5 


D23.0 


D23.2 


D23.1 


D21.2 


D21.1 


D22.2 


D22.1 


D24.2 


D21.3 
D21.3 


D21.4 
D21.4 


D21.7 
D21.7 


D21.6 
D21.6 


D21.4 
D21.4 


D21.6 
D21.6 


Table 24. Primitive Signals 


Primitive Beginning 


Idle Word Negative 


K28.5 D21.4 D21.5 D21.5 


K28.5 D21.4 D1i0.2 D10.2 


Receiver_Ready (R_RDY) 


Negative 
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Table 25. Primitive Sequences 


Sequence 


Offline (OLS) Negative K28.5 D21.1 D10.4 D21.2 


K28.5 D21.2 D31.5 D5.2 


Not_Operational (NOS) Negative 


Link_Reset (LR) Negative K28.5 D9.2 D31.5 D9I.2 


Link_Reset_Response (LRR) Negative K28.5 D21.1 D31.5 D9.2 


NOTES 
1. Each EOF-delimiter Ordered Set is defined 


such that negative Current Running Disparity 
will result after processing of the final (right- 
most) character of the Ordered Set. This, in 
combination with the Running Disparity 
Initialization rules specified in 10.2.2, 
ensures that the first Ordered Set following 
an EOF delimiter or Transmitter power on 
will always be transmitted with negative 
Beginning Running Disparity. The Ordered 
Sets defined for the primitive signals and 
primitive sequences preserve this negative 
Disparity, ensuring that the Ordered Sets 
associated with SOF delimiters, primitive 
signals, and primitive sequences will also 
always be transmitted with negative Begin- 
ning Running Disparity. As a result, primi- 
tive signal, primitive sequence, and SOF 
delimiter Ordered Sets are defined for the 
negative Beginning Running Disparity case 


only. (The primary benefit of such a defi- | 


nition is that it allows idle words to be 
removed and added from an encoded bit 
stream one word at a time without altering 
the Beginning Running Disparity associated 
with the Transmission Word subsequent to 
the removed idle word.) 


. The K28.5 Special Character is chosen as 
the first character of all Ordered Sets for the 
following reasons: 


- Bits abcdeif make up a Comma; this is 
a singular bit pattern which in the 
absence of transmission errors cannot 
appear in any other location of a Trans- 
mission Character and cannot be gener- 
ated across the boundaries of any two 


adjacent Transmission Characters. The 
Comma can be used to easily find and 
verify character and word boundaries of 
the received bit stream. 


- The encoded character presents a high 
number of transitions, simplifying 
Receiver acquisition of bit synchroniza- 
tion. 


3. The second character of the Ordered Sets 


used to represent EOF delimiters differen- 
tiates between normal and invalid frames. It 
also ensures that the Running Disparity 
resulting after processing of an EOF Ordered 
Set is negative independent of the value of 
Beginning Running Disparity. In all other 
Ordered Sets, it serves. only as a 
placeholder which provides a high number of 
bit transitions. 


. The third and fourth characters of the delim- 


iter functions, Receiver Ready, and the idle 
word are repeated to ensure that an error 
affecting a single character will not result in 
the recognition of an Ordered Set other than 
the one transmitted. The third and fourth 
characters of the other Ordered Sets defined 


by the standard have been selected to 


provide distinct patterns which: provide a 
large number of transitions and good spec- 
tral characteristics. 


. The categories of Delimiter, Primitive Signal, 


and Primitive Sequence have meaning to 
FC-2 and are defined by FC-2. FC-1 recog- 
nizes the character combinations defined in 
this section as Ordered Sets only. 


. More Ordered Sets may be defined as the 


standard progresses. 
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11 State description 


11.1 Receiver state description 


Whenever a signal (as defined by FC-0 in 5.6) is 
present on a Fibre, the Receiver attached to that 
Fibre shall attempt to achieve synchronization 
on both bit and Transmission-Word boundaries 
of the received encoded bit stream. Bit synchro- 
nization is defined by FC-0 in 5.5. Transmission- 
Word synchronization is defined in 11.1.2.2. 
synchronization failures on either’ bit or 
Transmission-Word boundaries are not sepa- 
rately identifiable and cause loss-of- 
synchronization errors. such failures may 
ultimately cause a Receiver to become Not 
Operational. 


11.1.1 Receiver states 


The Receiver state diagram is shown in figure 
32. 


11.1.1.1 Operational states 


Synchronization to Transmission-Word bounda- 
ries, hereafter referred to as Synchronization, is 
achieved when the Receiver has identified the 
Transmission-Word boundary as the one that is 
established by the input signal from the Trans- 
mitter at the other end of the Fibre. The proce- 
dure used to achieve this condition is described 
in 11.1.2.2. When this condition is achieved, the 
Receiver shall enter the Synchronization- 
Acquired _ state. | A Receiver in the 
Synchronization-Acquired state shall provide to 
the FC-2 level information that has been 
received from its attached Fibre and decoded. 


When the Transmission-Word boundary identified 
by the Receiver no longer matches the boundary 
established by the Transmitter to which it is con- 
nected, the Receiver shall enter the Loss-Of- 
Synchronization state. Such a Receiver shall 
remain Operational but shall cease to provide 
received and decoded information to the FC-2 
level. When the Receiver is in the Loss-Of- 
Synchronization state, the procedure described 


in 11.1.2 shall be used to regain Synchronization. | 


When the Receiver is in the Synchronization- 
Acquired state and receives a request to enter 
the Offline state from FC-2, it shall enter the 
Offline state. (See 27 for a discussion of Primi- 


54 


tive Sequences and their relationship to the 
Offline state.) Such a Receiver shall remain 
Operational and shall provide to the FC-2 level 
information that has been received from its 
attached Fibre and decoded. It shall also con- 
tinue to process received Transmission Words 
under the rules specified by “Invalid Trans- 
mission Word rules.” See 11.1.4 for additional 
details. 


When the Receiver is Operational, it is always in 
one of the three states described above. The 
determination of an Operational Receiver’s state 
is based on the conditions described in 11.1.2 
and 11.1.3 and upon the presence or absence of 
the FC-2 requests associated with entry and exit 
of the Offline state. 


11.1.1.2 Not Operational states 


If an Operational Receiver remains in the Loss- 
Of-Synchronization state for longer than an 
extended period of time as defined by FC-O in 
5.6, an FC-1-level-Receiver-failure condition shall 
be recognized and the Receiver shall become 
Not Operational. If a loss-of-signal condition is 
not detected by the FC-0 Receiver at the time of 
failure recognition, this condition shall be 
reported to FC-2 as a_ loss-of-Synchronization 
failure condition and the Receiver shall enter the 
Loss-Of-Synchronization-Failure state. If a loss- 
of-signal condition is detected by the FC-0O 
Receiver at the time of failure recognition, this 
condition shall be reported to FC-2 as a loss-of- 
signal failure condition and the Receiver shall 
enter the Loss-Of-Signal-Failure state. (Signal 
detection is discussed by FC-O in 5.6.) 


A Receiver shall become Not Operational and 
shall enter the Reset state when a reset condi- 
tion is imposed upon it, either internally or 
externally. 


11.1.2 Entry into 
Synchronization-Acquired state 


A Receiver shall enter into the Synchronization- 
Acquired state when it has achieved both bit and 
Transmission-Word synchronization. It shall also 
enter the Synchronization-Acquired state upon 
receipt of a request from FC-2 to exit the Offline 
state while currently in that state as the result of 


a prior FC-2 request. (See 27 for a discussion of 
Primitive Sequences and their relationship to the 
Offline state.) 


11.1.2.1 Bit synchronization 


An Operational Receiver that is in the Loss-Of- 
Synchronization state shall first acquire bit syn- 
chronization before attempting to acquire 
Transmission-Word synchronization. Bit syn- 
chronization is defined by FC-0 in 5.5. After 
achieving bit synchronization, the Receiver shall 
remain in the Loss-Of-Synchronization state until 
it achieves Transmission-Word synchronization. 


11.1.2.2 Transmission-Word synchronization 


When an Operational Receiver that is in the 
Loss-Of-Synchronization state and that has 
acquired bit synchronization recognizes three 
Ordered Sets, as specified in tables 23, 24, and 
25, without an intervening invalid Transmission 
Word, as specified by “Invalid Transmission 
Word rules,” the Receiver shall enter the 
Synchronization-Acquired state. The third recog- 
nized Ordered Set shall be considered valid 
information and shall be decoded and provided 
to the FC-2 level. Ordered Set recognition shall 
include not only recognition of the individual 
characters that make up an Ordered Set but also 
proper alignment of those characters (i.e., the 
Special Character used to designate an Ordered 
Set shall be aligned in the leading character 
position of the received Transmission Word). 
The method used by the Receiver to align and 
recognize Ordered Sets is not defined by this 
standard. 


NOTES 


1. The Comma contained within the K28.5 
Special Character is a singular bit pattern 
which in the absence of transmission errors 
cannot appear in any other location of a 
Transmission Character and cannot be gen- 
erated across the boundaries of any two 
adjacent Transmission Characters. This bit 
pattern is sufficient to identify the word align- 
ment of the received bit stream. 


2. The recommended electrical interface allows 
the word alignment function to be enabled in 
either of two modes: 
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- Continuously-enabled word alignment 
(continuous-mode alignment) 


- Explicitly-enabled word 
(explicit-mode alignment) 


alignment 


Continuous-mode alignment allows the FC-1 
Receiver to reestablish word alignment at 
any point in the incoming bit stream while 
the Receiver is Operational. Such realign- 
ment is likely (but not guaranteed) to result 
in Code Violations and subsequent loss of 
Synchronization. Under certain conditions, it 
may be possible to realign an incoming bit 
stream without loss of Synchronization. _ If 
such a realignment occurs within a received 
frame, detection of the resulting error condi- 
tion is dependent upon FC-2 function (e.g., 
invalid CRC, missing EOF Delimiter). 


- Explicit-mode alignment allows the FC-1 
Receiver to reestablish word alignment only 
while in the Loss-Of-Synchronization state or 
when Synchronization has been lost in the 
Offline state. Once Synchronization has 
been acquired, the word alignment function 
of the Receiver is disabled. 


11.1.3 Entry into 
Loss-Of-Synchronization state 


The four conditions which shall cause an Opera- 
tional Receiver to enter the — Loss-Of- 
Synchronization state are: 


- Completion of the Loss-Of-Synchronization 
procedure 

- Transition to power on 

- Exit from Receiver reset condition 

- Detection of loss of signal 


NOTE - While in the Loss-Of-Synchronization 
state, the FC-1 Receiver may request that the 
FC-0 Receiver attempt bit resynchronization. In 
some instances, this may allow the FC-1 
Receiver to regain Synchronization and enter the 
Synchronization-Acquired state when it other- 
wise would be forced to enter a Not Operational 
state. However, initiation of bit resynchroniza- 
tion at the FC-O Receiver may also delay the 
resynchronization process by forcing the FC-0 
Receiver to reestablish a clock reference when 
such reestablishment is otherwise unnecessary. 
See 5.5 in FC-O for a detailed discussion of bit 
synchronization. 
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11.1.3.1 Loss-of-Synchronization procedure 


The loss-of-Synchronization procedure defines 
the method by which the Receiver changes from 
the Synchronization-Acquired state to the Loss- 
Of-Synchronization state. The procedure tests 
each received Transmission Word according to 
the rules defined in “Invalid Transmission Word 
rules” to determine the validity of the Trans- 
mission Word. 


Starting in the Synchronization-Acquired state, 
the Receiver shall check each received Trans- 
mission Word according to the rules of “Invalid 
Transmission Word rules” to determine if the 
word is valid. The Receiver shall continue to 
check the Transmission Words and shall remain 
in the Synchronization-Acquired state until the 
loss-of-Synchronization procedure, as described 
by “Loss-of-Synchronization-procedure states,” 
is completed. 


Invalid Transmission Word rules 


An invalid Transmission Word shall be recog- 
nized by the Receiver when one of the following 
conditions is detected: 


- A Code Violation on a character basis, as 
specified by tables 21 and 22, is detected 
within a Transmission Word. This is referred 
to as a Code Violation condition. 


- Any valid Special Character is detected in 
the second, third, or fourth character position 
of a Transmission Word. This is referred to 
as an invalid Special Code alignment condi- 
tion. 


- Any valid Special Character other than 
K28.5 is detected in the first (leftmost) char- 
acter position of a Transmission Word. This 
is referred to as a reserved Special Code 
Violation condition. 


Loss-of-Synchronization-procedure states 
The following five detection states are defined as 
part of the loss-of-Synchronization procedure: 


1. No invalid Transmission Word has been 
detected (the No-Invalid-Transmission-Word 
detection state). 


2. The first invalid Transmission Word is 
detected (the First-Invalid-Transmission-Word 
detection state). 
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3. The second invalid Transmission Word is 
detected (the Second-Invalid-Transmission- 
Word detection state). 


4. The third invalid Transmission Word is 
detected (the Third-Invalid-Transmission- 
Word detection state). 


5. The fourth invalid Transmission Word is 
detected (the Fourth-Invalid-Transmission- 
Word detection state). 


A Receiver in the Synchronization-Acquired state 
may be in any of the first four detection states 
listed above. A Receiver in the fifth detection 
state listed above (the Fourth-Invalid- 
Transmission-Word detection state) shall enter 
the Loss-Of-Synchronization state. 


When the procedure is in detection state 1, 
checking for an invalid Transmission Word shall 
be performed. After each invalid Transmission 
Word is detected, one of the detection states 2 
through 5 shall be entered. When the procedure 
is in detection state 2, 3, or 4, checking for addi- 
tional invalid Transmission Words shall be per- 
formed in groups of two consecutive 
Transmission Words. If two consecutive valid 
Transmission Words are received, the count of 
previously detected invalid Transmission Words 
shall be reduced by one, and the previous 
detection state shall be entered. The loss-of- 
Synchronization procedure is completed when 
detection state 5 is entered. 


The  No-Invalid-Transmission-Word detection 
state shall be entered on a transition to the 
Synchronization-Acquired state due to acquisi- 
tion of Synchronization, or after the First-Invalid- 
Transmission-Word detection state is reset. 


The First-Invalid-Transmission-Word detection 
state shall be entered after the first invalid 
Transmission Word is detected or after the pre- 
vious detection state (detection of the second 
invalid Transmission Word) is reset. Subsequent 
Transmission Words received shall be checked 
to determine whether an additional invalid 
Transmission Word is detected within the next 
consecutive two or fewer Transmission Words 
received. If an additional invalid Transmission 
Word is detected within the next consecutive two 
or fewer Transmission Words received, the 
Second-Invalid-Transmission-Word detection 
state shall be entered. If two consecutive valid 
Transmission Words are received, the No- 


Invalid-Transmission-Word detection state shall 
be entered. 


The Second-Invalid-Transmission-Word detection 
state shall be entered after the second invalid 
Transmission Word is detected or after the pre- 
vious detection state (detection of the third 
invalid Transmission Word) is reset. Subsequent 
Transmission Words received shall be checked 
to determine whether an_ additional invalid 
Transmission Word is detected within the next 
consecutive two or fewer Transmission Words 
received. If an additional invalid Transmission 
Word is detected within the next consecutive two 
or fewer Transmission Words received, the 
Third-Invalid-Transmission-Word detection state 
shall be entered. If two consecutive valid Trans- 
mission Words are received, the First-Invalid- 
Transmission-Word detection state shall be 
entered. 


The Third-Invalid-Transmission-Word detection 
state shall be entered after the third invalid 
Transmission Word is detected. Subsequent 
Transmission Words received shall be checked 
to determine whether an _ additional invalid 
Transmission Word is detected within the next 
consecutive two or fewer Transmission Words 
received. If an additional invalid Transmission 
Word is detected within the next consecutive two 
or fewer Transmission Words received, the 
Fourth-Invalid-Transmission-Word detection state 
shall be entered and the Receiver shall imme- 
diately enter the Loss-Of-Synchronization state. 
If two consecutive valid Transmission Words are 
received, the Second-Invalid-Transmission-Word 
detection state shall be entered. 


The Fourth-Invalid-Transmission-Word detection 
state shall be entered after the fourth invalid 
Transmission Word is detected. Upon entering 
this detection state, the Receiver shall imme- 
diately enter the Loss-Of-Synchronization state. 
Subsequent Transmission Words received shall 
not be checked as the loss-of-Synchronization 
procedure is complete. The Receiver shall 
remain in the Loss-Of-Synchronization state until 
one of the following occurs: 


- The Receiver regains Synchronization 
- The Receiver is reset 


- The Receiver recognizes an 
FC-1-level-Receiver-failure condition, 
becomes Not Operational, and enters one of 
the two failure states (Loss-Of- 
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Synchronization-Failure or 
Failure) 


Loss-Of-Signal- 


The following figure graphically portrays the 
Loss-of-Synchronization procedure. States 1 
through 5 are keyed to the detection states 
described by the ordered list at the beginning of 
this section. State 1 is the initial detection state 
entered by a Receiver upon acquisition of Syn- 
chronization. States 1 through 4 are detection 
states which are possible only when the 
Receiver has achieved Synchronization. Entry 
into State 5 results in loss of Receiver Synchro- 
nization. 


1> 3> 
State 1 State 2 State 3 
+2 <4 
—_— 5 66 
fee ee 
Not Op 

| State |<-9 State 5 j4/ State 4 
Dace ose cs, eho 


Figure 31. Loss-of-Synchronization procedure 
state diagram 


State Transition Conditions: 


1. The first 
detected 


invalid Transmission Word is 


2. An additional invalid Transmission Word is 
not detected in the next two consecutive 
Transmission Words 


3. An additional invalid Transmission Word is 
detected in the next two consecutive Trans- 
mission Words 


4. An additional invalid Transmission Word is. 
not detected in the next two consecutive 
Transmission Words 


5. An additional tnvalid Transmission Word is 
detected in the next two consecutive Trans- 
mission Words 


6. An additional invalid Transmission Word is 
not detected in the next two consecutive 
Transmission Words 


7. An additional invalid Transmission Word is 
detected in the next two consecutive Trans- 
mission Words 
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8. The Receiver regains Synchronization 


9. The Receiver is Reset or recognizes an 
FC-1-level-Receiver-failure condition 


NOTE - The~ rationale for the _ loss-of- 
Synchronization procedure is to reduce the like- 
lihood that a single error will result in a loss of 
Synchronization. For example, a single two-bit 
error positioned to overlap two Transmission 
Words could result in the detection of three 
invalid Transmission Words; the two Trans- 
mission Words directly affected by the error and 
a subsequent Transmission Word which was 
affected by a disparity change resulting from the 
error. The procedure described above would 
maintain Synchronization in such a case. 


11.1.3.2 Transition to power on 


When the Receiver is Operational after being 
powered on, the Receiver shall enter the Loss- 
Of-Synchronization state. 


11.1.3.3 Exit From Receiver reset condition 


When the Receiver is Operational after exiting 
from a Receiver reset condition imposed upon it, 
either externally or internally, and was not previ- 
ously in the Offline state, the Receiver shall 
enter the Loss-Of-Synchronization state. 


NOTE - The conditions required for a Receiver in 
the Reset state to exit that state are not defined 
by this standard. Such conditions may be based 
on explicit indications. They may also be time- 
dependent in nature. 


11.1.3.4 Detection of loss of signal 


When a loss-of-signal condition is recognized by 
an Operational Receiver, the Loss-Of- 
Synchronization state shall be entered (if the 
Receiver is not presently in that state). The 
Receiver shall remain in this state until one of 
the following conditions occur: 


- The loss-of-signal condition is corrected 
and Synchronization is regained 


- The Receiver is reset 


- The Receiver recognizes an 
FC-1-level-Receiver-failure condition, 
becomes Not Operational, and enters the 
Loss-Of-Signal-Failure state 
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11.1.4 Entry into Offline state 


When a request to enter the Offline state is 
received from FC-2 by an Operational FC-1 
Receiver, the Offline state shall be entered. The 
Receiver shall remain in the Offline state until it 
receives a request from FC-2 to exit the Offline 
state. (See 2/7 for a discussion of Primitive 
Sequences and their relationship to the Offline 
state.) This request may take the form of a 
request to return to the Synchronization- 
Acquired state or a reset request. A Receiver in 
the Offline state that is reset shall return to the 
Offline state upon completion of the reset. 


While in the Offline state, the FC-1 Receiver shall 
remain Operational and shall provide received 
and decoded information to the FC-2 level 
according to the rules specified by “Invalid 
Transmission Word rules.” The Receiver shall 
also continue to process received Transmission 
Words under the rules of the  Loss-of- 
Synchronization procedure specified in “Invalid 
Transmission Word rules.” Consequently, while 
in the Offline state, the Receiver may lose Syn- 
chronization. In addition, it may also detect a 
loss of signal condition. Such conditions shall 
not cause the Receiver to leave the Offline state. 
Instead, a Receiver in the Offline state which 
encounters such conditions shall attempt to 
reacquire Synchronization according to the rules 
described in 11.1.2 when such conditions occur. 


11.1.5 Entry into Not Operational states 


The two conditions which shall cause an Opera- 
tional Receiver to enter one of the Not Opera- 
tional states are: 


- Recognition of FC-1-Level-Receiver-Failure 
condition 
- Imposition of Receiver reset condition 


11.1.5.1 Recognition of 
FC-1-level-Receiver-failure condition 


A Receiver shall enter into the Loss-Of- 
Synchronization-Failure or Loss-Of-Signal-Failure 
state based upon the conditions present at the 
time of FC-1-level-Receiver-failure condition 
recognition. Once one of these failure states is 
entered, the Receiver shall become Not Opera- 
tional and shall remain in a failure state until it 
is subsequently made Operational through 
external intervention. Transitions between the 
Loss-Of-Synchronization-Failure and Loss-Of- 


Signal-Failure states may occur as the result of 
changes to the output of the FC-0 signal 
detection function. 


Signal detection is an optional function of FC-O. 
When a failure condition is recognized by an 
FC-1 Receiver and the signal detection function 
is not provided by FC-0, the  Loss-Of- 
Synchronization-Failure state shall be entered. 
(Signal detection is discussed by FC-O in 5.6.) 


11.1.5.2 Imposition of Receiver reset condition 


When a Receiver reset condition is imposed on 
a Receiver, either internally or externally, the 
Receiver shall enter the Reset state. Once the 
Reset state is entered, the Receiver shall 
become Not Operational (if not already Not 
Operational as a result of previously entering 
one of the failure states) and shall remain in the 
Reset state until it is subsequently made Opera- 
tional by exiting the Receiver reset condition. 


NOTES 


1. A typical use of Receiver reset is to force a 
Receiver in the Loss-Of-Synchronization or 
Loss-Of-Synchronization-Failure state to 
attempt reacquisition of bit synchronization. 
(Note that entry into either of these states 
does not necessarily indicate loss of bit syn- 
chronization.) As such, an FC-1 Receiver 
reset may result in a request for bit resyn- 
chronization to the FC-0 Receiver. 


2. The conditions required for a Receiver in the. 


Reset state to exit that state are not defined 
by this standard. Such conditions may be 
based on explicit indications. They may also 
be time-dependent in nature. 


11.2 Receiver state diagram 


10. Exiting of 
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Figure 32. FC-1 Receiver state diagram 


State Transition Conditions: 
1. Acquisition of Synchronization (see 11.1.2) 


2. Receipt of Receiver Offline request from FC-2 
(see 11.1.4) 


3. Receipt of Receiver request to return to 
Synchronization-Acquired state from FC-2 
(see 11.1.2) 


4. Completion of loss-of-Synchronization proce- 
dure (see 11.1.3.1) | 


5. Receipt of Receiver reset request from FC-2 
(see 11.1.5.2) 


6. Receipt of Receiver reset request from FC-2 
(see 11.1.5.2) 


7. Receipt of Receiver reset request from FC-2 
(see 11.1.5.2) 


8. Receipt of Receiver reset request from FC-2 
(see 11.1.5.2) 


9. Receipt of Receiver reset request from FC-2 
(see 11.1.5.2) 


Receiver reset condition -- 
Receiver previously not in Offline state (see 
11.1.3.3) 


11. Elapsed time since entry into 
Loss_Of_Synchronization state =~ an 
extended period of time as defined by FC-0 
and signal currently present on attached 
Fibre (see 11.1.1.2 and 11.1.5.1) 


12. Elapsed time since entry into 
Loss Of Synchronization state = — an 
extended period of time as defined by FC-0 
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and signal currently not present on attached 
Fibre (see 11.1.1.2 and 11.1.5.1) 


13. Signal currently not present on attached 
Fibre (see 11.1.5.1) 


14. Signal currently present on attached Fibre 
(see 11.1.5.1) 


15. Exiting of Receiver reset condition -- 
Receiver previously in Offline state (see 
11.1.4) 


16. Completion of loss-of-Synchronization proce- 
dure (see 11.1.4) 


17. Detection of a loss of signal condition (see 
11.1.4) 


18. Acquisition of Synchronization (see 11.1.4) 


NOTES 


1. The Loss _Of_ Synchronization state is the 
default state upon completion of Receiver 
Initialization. 


2. The data path width of a variable-path-width 
Receiver shall be established before that 
Receiver may enter the 
synchronization Acquired state. 


3. The Receiver may be in either Loopback or 
normal mode when in states denoted by * 
(see 13 for a discussion of Loopback mode). 


4. The Loss-Of-Signal-Failure state will never 
be entered by a Receiver if FC-0 does not 
provide a signal detection function. 


11.3 Transmitter state description 


While Operational and not disabled, a Trans- 
mitter attached to a Fibre shall constantly 
attempt to transmit an encoded bit stream onto 
that Fibre. Some Transmitters are capable of 
monitoring this transmitted signal and verifying 
its validity. Such Transmitters may become Not 
Operational as a result of this monitoring. 
Transmitters shall also become Not Operational 
if requests for information transfer not consistent 
with the transmission rules established by FC-1 
are received. A Transmitter may also be placed 
in a disabled state under certain internal or 
external conditions. 


The Transmitter state diagram is shown in figure 
33. 
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11.3.1 Transmitter states 


11.3.1.1 Operational states 


A Transmitter actively attempting to transmit an 
encoded bit stream onto its attached Fibre is 
defined to be in the Working state. 


Under certain conditions, it may be necessary or 
desirable to cease the transmission of signals by 
a Transmitter onto its attached Fibre. A Trans- 
mitter that has ceased transmission is in the 
Not-Enabled state. A Transmitter in the Not- 
Enabled state shall remain Operational. 


NOTE - A Transmitter in the Not-Enabled state is 
free to transmit those signals associated with 
laser safety procedures. See 15 for additional 
information related to laser safety. 


11.3.1.2 Not Operational states 


A Transmitter shall become Not Operational and 
shall enter the Fai/ure state under certain condi- 
tions. One determination of the Transmitter’s 
state is based on signat monitoring rules not 
defined by this standard. The Transmitter’s 
state is also based on monitoring of requests for 
information transfer to ensure consistency with 
the transmission rules established by FC-1 (see 
11.3.4.1). 


An FC-1-level-Transmitter-failure condition shall 
be recognized and reported to FC-2 when the 
Transmitter becomes Not Operational and enters 
the Failure state. | 


11.3.2 Entry into Working state 


An Operational Transmitter shall enter the 
Working state when its Transmitter becomes 
enabled. A Transmitter shall become enabled 
under either of the following conditions: 


- Processing of an FC-1 request to enter the 
enabled state when the Receiver was not 
placed in the Not-Enabled state as a result of 
laser safety procedures 


- Determination by the FC-0O laser safety pro- 
cedures that a laser safety condition (i.e., a 
condition which requires that the Transmitter 
cease transmission) no longer exists 


| 
| 


11.3.3 Entry into Not-Enabled state 


Entry into the Not-Enabled state may result from 
error conditions detected externally by the Link 
Control Facility, or it may result from internally 
generated signals. Specific conditions under 
which the Transmitter shall enter the Not- 
Enabled state are as follows: 


- Completion of Transmitter Initialization 


- Processing of an FC-1 request to enter the 
Not-Enabled state 


- Determination by the FC-0 laser safety pro- 
cedures that a laser safety condition exists 


The Transmitter shall remain in the Not-Enabled 
state until the conditions causing it to cease 
transmission are removed. 


11.3.4 Entry into Failure state 


A Transmitter shall enter into the Failure state 
under the following conditions: 


- Detection of a request for information 
transfer that is not consistent with the trans- 
mission rules established by FC-1 while in 
the Working or Not-Enabled state 


- Recognition (via signal monitoring) of an 
FC-1-level-Transmitter-failure condition while 
in the Working state 


Once the Failure state is entered, the Trans- 
mitter shall become Not Operational and shall 
remain in the Failure state until it is subse- 
quently made Operational through external inter- 
vention. 


11.3.4.1 Transmission rules 


Requests for information transfer shall conform 
to the following rules in order for an FC-1 Trans- 
mitter to consider them valid requests: 


- Requests for Ordered Set transmission 
shall be aligned with the word alignment 
established by the Transmitter upon entry 
into the Working state. 


- Requests for Valid Data Byte transmission 
shall be aligned with the byte alignment 
established by the Transmitter upon entry 
into the Working state. Each byte of a four- 
byte word is aligned based on the estab- 
lished word alignment. 
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The following requests for information transfer 
are inconsistent with the transmission § rules 
established by FC-1 and shall cause a Trans- 
mitter to enter the Failure state: 


- Transmission requests improperly aligned 
with transmission (word and byte) bounda- 
ries 


- Transmission requests not consistent with 
the currently active transmission boundary 


- Requests for Ordered Set transfers on 
a non-word boundary 


- Requests for data transfers overlapping 
an Ordered Set transfer currently in 
progress 


- Lack of transmission requests (i.e., addi- 
tional bytes required to complete a Trans- 
mission Word) when a Transmission Word 
has been partially transmitted as a result of 
prior transmission requests 


11.3.4.2 Transmitter signal monitoring 


Each Transmitter capable of monitoring its trans- 
mitted signal shall define a method by which this 
monitoring is to take place. It shall also define 
the conditions necessary to cause the Trans- 
mitter to recognize an 
FC-1-level-Transmitter-failure | condition and 
change from the Working state to the Failure 
state. 


NOTE - Monitoring of average light levels is a 
typical method of Transmitter monitoring. Typi- 
cally, an error condition is detected when the 
transmitted light level of a Transmitter falls 
outside of the range of allowed values specified 
by FC-0O for its Transmitter class. (See 5.2 in 
FC-0 for a discussion of signal monitoring.) 


11.4 Transmitter state diagram 
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Figure 33. FC-1 Transmitter state diagram 
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State Transition Conditions: 
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. Receipt of Transmitter enable request from 


FC-2 when Transmitter was not previously 
disabled as a result of a laser safety condi- 
tion (see 11.3.2) 


. Determination by FC-0O that a laser safety 


condition no longer exists (see 11.3.2) 


. Receipt of Transmitter disable request from 


FC-2 (see 11.3.3) 


. Determination by FC-O that a laser safety 


condition exists (see 11.3.3) 


. Detection by FC-0 of a Transmitter failure 


condition (see 11.3.4) 


. Detection of a request for information 


transfer inconsistent with the transmission 
rules established by FC-1 (see 11.3.4) 


7. Receipt of Transmitter enable request from 


FC-2 when Transmitter was previously disa- 
bled as a result of a laser safety condition 
(see 11.3.3) 


_ Detection of a request for information 


transfer inconsistent with the transmission 
rules established by FC-1 (see 11.3.4) 


NOTES 
1. The Not_Enabled state is the default state 


upon completion of Transmitter Initialization. 


. The data path width of a variable-path-width 


Transmitter shall be established before that 
Transmitter may enter the Working state. 


. The Transmitter may be in either Loopback 


or normal mode when in states denoted by * 
(see 13 for a discussion of Loopback mode). 


12 Clock reference 


A clock reference is provided by FC-1 to ensure 
that a gross frequency reference is available for 
the FC-O0 Receiver to lock onto as a precursor to 
attempting bit synchronization based on the 
incoming bit stream. The method used to 


13 Loopback mode 


Loopback mode is provided by FC-1 as a diag- 
nostic function to FC-2. When in Loopback 
mode, transmission requests passed to the FC-1 
Transmitter shall be shunted directly to the FC-1 
Receiver, overriding any signal detected by the 
Receiver on its attached Fibre. A Link Control 
Facility must be explicitly placed in Loopback 
mode (i.e., Loopback mode is not the normal 
mode of operation of a Link Control Facility). 
The method of implementing Loopback mode is 
not defined by this standard. 


NOTE - Loopback mode may be implemented 
either in the parallel or the serial circuitry of a 
Link Control Facility. As such, it may be imple- 
mented entirely within FC-1 or may be imple- 
mented by the combination of FC-1 and FC-O. 
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provide this reference is not defined by this 
standard. 


NOTE - See C.4 for the recommended usage of 
this clock reference. 


13.1 Receiver considerations 


A Receiver in the Loss-Of-Synchronization or 
Synchronization-Acquired state may be placed in 
Loopback mode. A Receiver in any other state 
shall not be placed in Loopback mode. 


Entry into or exit from Loopback mode may 
result in a temporary loss of Synchronization. 
Under such conditions, decoded _ information 
shall not be presented by the FC-1 Receiver to 
FC-2 until Synchronization has been reestab- 
lished. 


13.2 Transmitter considerations 


A Transmitter in the Working or Not-Enabled 
state may be placed in Loopback mode. A 
Transmitter in any other state shall not be 
placed in Loopback mode. The external 
behavior of a Transmitter (i.e., the activity of a 
Transmitter with respect to its attached Fibre) 
simultaneously in the Working state and in 
Loopback mode is unpredictable. 
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14 Diagnostic mode 


Diagnostic functions may be provided at the FC-1 
level by certain implementations. Compliance 
with the standard shall not be affected by the 
provision or exclusion of such functions by an 
implementation, and any functions that are pro- 
vided by an implementation are not defined by 
the standard. 


NOTE - A typical diagnostic function is the ability 
to transmit invalid Transmission Characters 


15 Transmitter safety 


Certain FC-0 Transmitter classes require special 
procedures to ensure that Class 1 laser safety 
standards are met. These procedures have the 
following effect on the FC-1 definition: 


1. A special Transmitter state (the Not-Enabled 
state) is defined. 


2. When the FC-0 laser safety procedures 
determine that a laser safety condition (i.e., 
a condition which requires that the Trans- 
mitter cease transmission) exists, the Trans- 
mitter shall enter the Not-Enabled state. 
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within an otherwise valid bit stream. Certain 
combinations of invalid Transmission Characters 
may damage certain FC-O components (e.g., a 
bit stream of continuous ‘1’s may overheat an 
LED Transmitter, resulting in a reduced lifetime 
for that Transmitter). Other invalid bit streams 
may cause a Receiver to lose word and/or bit 
synchronization. See 5.4 in FC-0 for a more 


detailed discussion of Receiver and Transmitter 


behavior under various diagnostic conditions. 


3. When the FC-O laser safety procedures 
determine that a laser safety condition no 
longer exists, the Transmitter shall exit the 
Not-Enabled state. 


4. FC-1 requests are incapable of forcing a 
Transmitter which enters the Not-Enabled 
state as a result of FC-O laser safety proce- 
dures to exit that state. 


For a detailed description of the laser safety pro- 
cedures defined for the Fiber Channel Standard, 
see 6.2.3 in FC-O0. 
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FC-2 level - Signaling protocol 


16 Ordered Sets 


16.1 Introduction 


An Ordered Set is a four-byte combination of 
data and special transmission characters which 
is designated by the standard to have special 
meaning. Ordered Sets provide the ability to 
obtain bit and word synchronization which also 
establishes word boundary alignment. See FC-1 
for additional information on Ordered Sets and 
rules for synchronization. The following types of 
Ordered Sets are defined: 


— Start_of_ Frame delimiters 
— End_of_Frame delimiters 
— Primitive Signals 
— Idle 
— Receiver Ready (R_RDY) 
— Primitive Sequences 
— Not_Operational (NOS) 
— Offline (OLS) 
— Link_Reset (LR) 
— Link_Reset_Response (LRR) 


16.2 Frame delimiters 


A frame delimiter is an Ordered Set that imme- 
diately precedes or follows the contents of a 
frame. Separate and distinct delimiters identify 
the start of a frame and the end of a frame. 
Frame delimiters shall be recognized when a 
single Ordered Set is detected. 


16.2.1 Start_of_Frame (SOF) | 


The Start_of_Frame delimiter is an Ordered Set 
that immediately precedes the Frame Content. 
There are multiple SOF delimiters defined for 
Fabric and N_Port Sequence control. The SOF 
delimiter shall be transmitted on a word 
boundary. 


16.2.2 End_of_Frame (EOF) 


The End_of_ Frame (EOF) delimiter is an Ordered 
Set that immediately follows the Frame_Trailer 
and shall be transmitted on a word boundary. 
The EOF delimiter designates the end of the 
Frame Content and is followed by Idle words. 


16.3 Primitive Signals 


A Primitive Signal is an Ordered Set designated 
by the standard to have special meaning. Primi- 
tive Signals are recognized when a _ single 
Ordered Set is detected. (See FC-1 for details 
on ordered sets and the bit encodings for Primi- 
tive Signals). 


16.3.1 Idle Word (idles) 


An Idle Word is a Primitive Signal transmitted on 
the link to indicate an Operational Port facility 
ready for frame transmission and reception. Idle 
Words shall be transmitted on the link to obtain 
and maintain bit and word synchronization as 
well as word boundary alignment. 


Idle Words shall be transmitted on the _ link 
during those periods of time when frames, 
R_RDY, or other Primitive Sequences are not 
being transmitted. A word is composed of four 
transmission characters during transmission. A 
word within the Frame Content, prior to trans- 
mission and after reception, is composed of four 
valid data bytes. (See 17.1 regarding frame 
transmission.) 
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16.3.2 Receiver_Ready (R_RDY) 


The R_RDY Primitive Signal shall indicate that a 
single Class 1 connect-request (SOFc1), Class 2, 
or Class 3 frame was received and that the inter- 
face buffer which received the frame is available 
for further frame reception. Validity of the frame 
content is not required. Transmission of the 
R_RDY Primitive Signal shall be preceded and 
followed by a minimum of two Idle Words. 
(Since R_RDY is not passed through the Fabric, 
there is no requirement for additional Idles for 
clock skew management.) (See 17.1.) See 
20.3.2.1 for a discussion regarding the use of 
R_RDY in flow control in conjunction with ACK 
frames. 


16.4 Primitive Sequences 


A Primitive Sequence is an Ordered Set that is 
transmitted repeatedly and continuously. Primi- 
tive Sequences are transmitted to indicate spe- 
cific conditions within a Port (N_Port or F_Port) 
or conditions encountered by the Receiver logic 
of a Port. | 


Primitive Sequences are transmitted  contin- 
uously while the condition exists. When a Primi- 
tive Sequence is received and recognized, a 
corresponding Primitive Sequence or Idles are 
transmitted in response. The following Primitive 
Sequence Protocols are described in clause 27: 


— Link Initialization (see 27.3) 
— Online to Offline (see 27.4) 
— Link Failure (see 27.5) 

— Link Recovery (see 27.6) 


During a Class 1 Dedicated Connection, Primi- 
tive Sequences transmitted from an N Port to 
the entry F_Port of a Fabric shall remove an 
existing Class 1 Dedicated Connection. The 
Fabric entry F_Port shall respond appropriately 
to the Primitive Sequence received and _ shall 
notify the exit F_Port which shall transmit the 
Link Reset Primitive to the other Connected 
N_Port (ie., initiate Link Recovery). 


If a Class 1 Dedicated Connection does not exist, 
a Primitive Sequence transmitted by an N_Port 
shall be received and recognized by the F_Port, 
but not transmitted through the Fabric. 
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16.4.1 Primitive Sequence Recognition 


Recognition of a Primitive Sequence requires 
detection of three consecutive Ordered Sets of 
the same Ordered Set without any intervening 
code violation errors. 


16.4.2 Not_Operational (NOS) 


The Not Operational Primitive Sequence is 
transmitted to indicate that the Port transmitting 
this Sequence has detected a Link Failure condi- 
tion. 


Link failure conditions are defined as: 


— Loss of Synchronization for more than the 
timeout period while not in the Offline State, 
as defined in FC-1, 

— Loss of Signal while not in the Offline State, 
as defined in FC-1, or 

— Timeout during the Link Recovery Protocol 
(see 27.6). 


NOS shall be transmitted continuously as a 
Primitive Sequence. The Port transmitting NOS 
shall transmit the Sequence as long as the Link 
Failure condition exists, and until the Offline 
Sequence (OLS) is received. 


Receiving NOS 


A Port recognizing NOS shall transmit the Offline 
Sequence (OLS) in response. 


16.4.3 Offline (OLS) 


The Offline Primitive Sequence is transmitted to 
indicate that the Port transmitting this Sequence 
is: 

— receiving and recognizing NOS, 

— entering the Offline State, or 

— exiting the Offline State. 


Entry into Offline State 


A Port enters the Offline Transmit State to notify 
an attached Port that it is preparing to: 


— perform power-on initialization, 

— reinitialize, 

— perform diagnostic procedures, or 
— power-down. 


To enter the Offline State, a Port performs the 
Online to Offline Protocol as specified in 27.4. 
While the Port is in the Offline State, it may 
perform diagnostic procedures, turn off its trans- 
mitter, and transmit any signal (excluding Link 
Reset Response) without errors being detected 
by the other attached Port. While in the Offline 
State, a Port may also power-down. 


Exiting Offline State 


A Port exits the Offline State when initialization 
or diagnostics are complete by performing the 
Link Initialization Protocol specified in 27.3. 


Receiving OLS 


A Port receiving and recognizing OLS shall enter 
the Offline Receive State and shall: 


1. transmit the Link Reset (LR) 
Sequence in response, and 

2. shall ignore Receiver errors such as Loss of 
synchronization or Loss of Signal. 


Primitive 


A Port in Offline Receive State exits this State 
when the Link Reset Response (LRR) Primitive 
Sequence is received and recognized. 


16.4.4 Link Reset (LR) 


The Link Reset Primitive Sequence is trans- 
mitted by a Port after a Link Timeout error has 
occurred, or the OLS Sequence is received and 
recognized. LR shall be transmitted contin- 
uously as a Primitive Sequence. 


In Class 1, a Link Timeout error is detected 
during a Dedicated Connection if Sequence time- 
outs have been detected for all active 
Sequences. 


In Class 1, 2, or 3, a Link Timeout error is 
detected if one or more R_RDY Primitive Signals 
is not received within the timeout period after 
the buffer-to-buffer Credit CNT has reached 
zero. 
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Receiving LR 


Link Reset Response (LRR) is transmitted after 
LR is received and recognized. 


Dedicated Connection 


In Class 1, an existing Dedicated Connection 
shall be removed and the end-to-end Credit 
associated with the Connected N Port shall be 
reset to the Login value. An N Port supporting 
Class 1 Service may also transmit the LR Primi- 
tive Sequence when it is unable to determine its 
Connection status. 


All Class 1 frame Sequences which are active in 
an N Port when LR is received and recognized, 
or transmitted shall be abnormally terminated. 
When the Link Reset Primitive is being trans- 
mitted by an N_ Port, all Class 1 frames received 
are discarded. See 28.8 for more discussion on 
Connection Recovery. 


R_RDY 


In Class 1, 2 and 3, the  buffer-to-buffer 
Credit_CNT within the N_ Port is reset to its Login 
value and an F_Port processes or discards any 
Class 1 connect-request, Class 2, or Class 3 
frame(s) currently held in the receive buffer 
associated with the outbound fibre of the 
attached N_ Port. end-to-end Credit is not 
affected. 


16.4.5 Link Reset Response (LRR) 


The Link Reset Response Primitive Sequence 
shall be transmitted by a Port to indicate that it 
is receiving and recognizes the LR Primitive 
Sequence. LRR shall be transmitted contin- 
uously as a Primitive Sequence. 


Receiving LRR 


After a Port receives and recognizes the LRR 
Sequence, it shall transmit the Idles. 
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17 Frame formats 


All FC-2 frames follow the general frame format 
as shown in figure 34. An FC-2 frame is com- 
posed of a Start_of_Frame delimiter, Frame 
Content, and an End_of Frame delimiter. The 


Frame Content 


(Bytes) (4) (24) (0 to 2112) 
Idle Words FRAME HEADER DATA FIELD 


General FC-2 Frame Format 


PAYLOAD 


Frame Content ts composed of a Frame_Header, 
Data Field, and CRC. 


(4) (Bytes) 


Idle Words 


(4) 


Figure 34. FC-2 general frame format 


17.1 Frame transmission 


Frame transmission shall be performed by 
inserting a frame immediately following a 
sequence of Idle Words. Idles are then trans- 
mitted immediately upon completion of frame 
transfer. 


At the transmitter there shall be a minimum of 
six Primitive Signals (Idle Words and R_RDY) 
between frames. A minimum of two Idles shall 
be guaranteed to precede the start (SOF) of 
each frame received by a destination N_ Port. 
The Fabric may insert or remove Idles as long 
as the destination receives at least two Idles 
preceding each frame. 


NOTE - See Annex N for Fabric requirements. 


17.2 Start_of_Frame (SOF) 


The Start_of_Frame delimiter is an Ordered Set 
that immediately precedes the Frame Content. 
There are multiple SOF delimiters defined for 
Fabric and N_ Port Sequence control. The SOF 
delimiter shall be transmitted on a word 
boundary. The bit encodings for the SOF delim- 
iters are defined in FC-1. 
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17.2.1 Start_of_Frame Connect Class 1 
(SOF c1) 


SOFci shall be used to request a Class 1 Dedi- 
cated Connection. The frame Data Field size is 
limited to the maximum size specified by the 
destination N_ Port or by the Fabric, if present, 
whichever size is smaller. The Data Field size is 
determined during the Login procedure. This 
delimiter also identifies the start of the first 
Sequence (ie. implicit SOFi1). | 


17.2.2 Start_of_Frame Initiate (SOFix) 


A Sequence is initiated and identified by using 
the SOFix delimiter in the first frame. SOFix is 
used to indicate SOFi1, SOFi2, or SOFi3. The fol- 
lowing three delimiters identify the start of a 
Sequence based on Class of Service. 


17.2.2.1 Start_of_Frame Initiate Class 1 
(SOFi1) 


The first Sequence is initiated with SOFct1. 
After Class 1 Service is established, all 
subsequent Sequences within a_ specific 
Dedicated Connection are initiated with 
SOFi1. 


17.2.2.2 Start_of_Frame Initiate Class 2 
(SOFi2) 


The SOFi2 shall be used on the first frame 
to initiate a Sequence for Class 2 Service. 


17.2.2.3  Start_of_Frame Initiate Class 3 
(SOFis3) 


The SOFi3 shall be used on the first frame 
to initiate a Sequence for Class 3 Service. 


17.2.3 Start_of_Frame Normal (SOFnx) 


The following three delimiters identify the start of 
all frames other than the first frame of a 
Sequence based on Class of Service. SOFnx is 
used to indicate SOFn1, SOFn2, or SOFn3. 


17.2.3.1 Start_of_Frame Normal Class 1 
(SOFn1) 


The SOFn1 shall be used for all frames 
except the first frame of a Sequence for 
Class 1 Service. 


17.2.3.2 Start_of_Frame Normal Class 2 
(SOFnz2) 


The SOFn2 shall be used for all frames 
except the first frame of a Sequence for 
Class 2 Service. 


17.2.3.3 Start_of_Frame Normal Class 3 
(SOFn3) 


The SOFn3 shall be used for all frames 
except the first frame of a Sequence for 
Class 3 Service. 


17.2.4 Start_of_Frame Fabric (SOFf) 


The SOFf shall be used by the Fabric for 
Fabric_Frames. If a Fabric Frame is received by 
an N_Port, the frame shall be discarded. See 
17.9 for description of Fabric Frame. 


17.3 Frame_Header 


The Frame_Header shall be the first field of the 
Frame Content and immediately follow the SOF 
for all frames. The Frame Header shall be 
transmitted on a word boundary. The 
Frame_Header is used to control link operations, 
control device protocol transfers, and detect 
sequence errors in the link transport facility. 
The Frame_Header is described in detail in 
clause 18. 
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17.4 Data Field 


The Data Field shall follow the Frame_Header. 
Two Frame Types are defined based on the 
value of the DL Bits (Bits 31-30) in the R_CTL 
field of the Frame Header. Data Fields are 
aligned on word boundaries. 


A discussion of FT_O (Link_Control) and FT_1 
(Data) frames is found in clause 20. The two 
Frame_ Types are: 


1. FT_0 (Data Field = 0 bytes) 


When the DL Bits are set to 1 1, an FT_O 
frame (Link Control) is specified which has a 
Data Field length of zero. 


2. FT 1 (Data Field = 0 to 2112 bytes) 


When the DL Bits are set to any values other 
than 1 1, an FT_1 frame (Data frame) is spec- 
ified whose Data Field size is a multiple of 
four bytes and ranges in size from O to 2112 
bytes. If any of the last three bytes are not 
meaningful, they shall contain fill bytes as 
specified in the F_CTL field in table 28. 


FT 1 frames may contain optional headers, 
as defined by the DF_CTL field as well as the 
Payload. Optional Data Field headers are 
described in clause 19. 


17.5 CRC 


The Cyclic Redundancy Check (CRC) is a four 
byte field that is used to verify the data integrity 
of the Frame_Header and Data Field. SOF and 
EOF delimiters are not included in the CRC ver- 
ification. The CRC field shall be calculated on 
the Frame Header and Data Field prior to 
encoding for transmission or after decoding 
upon reception. The CRC field shall be aligned 
on a word boundary. 


The CRC uses the following 32-bit polynomial 
(from the Fiber Distributed Data Interface Media 
Access Control document) and is described in 
Annex L. 


X32 + x26 + K23 4+ y22 4+ KI6 + X12 + yt + X10 
+ X8 + X7 + X5 + X4 + X2 +X 4+ 1 
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17.6 End_of_Frame (EOF) 


The End of Frame (EOF) delimiter is an Ordered 
Set that immediately follows the CRC. The EOF 
delimiter designates the end of the Frame 
Content and shall be followed by Idle words. 
There are three categories of EOF delimiters. 
One category of delimiter indicates that the 
frame contents are valid. The second category 
indicates that the frame contents are invalid. 
The third category indicates the frame content is 
corrupted and the frame was truncated during 
transmission. The bit encoding for the EOF 
delimiters is defined in FC-1. 


17.6.1 Valid frame content 


Three types of End _of_Frame delimiter are 
defined to indicate that the contents of the frame 
are valid. 


17.6.1.1 End_of_Frame Terminate (EOFt) 


The EOFt shall end the last frame of a 
Sequence and_ shall indicate that the 
Sequence associated with this SEQ _ID is 
complete. It is required to properly close a 
Sequence without error. 


17.6.1.2 End_of_Frame 
Disconnect_Terminate (EOFdt) 


The EOFdt shall remove a Class 1 Dedi- 
cated Connection through a Fabric, if 
present. The EOFat shall also identify the 
last ACK of a Sequence and indicate that 
all Sequences associated with this S_ID 
are terminated. Open Sequences, other 
than the SEQ ID specified in the frame con- 
taining EOFdt, shall be abnormally termi- 
nated and may require Sequence recovery 
(FC-4 protocol dependent). The EOFdt is 
only used for removing for Class 1 Service 
and is not applicable to Class 2 and Class 
3 Service. 


17.6.1.3 End_of_Frame Normal (EOFn) 
The EOFn shall identify the end of frame 


when one of the other EOF delimiters indi- 
cating valid frame contents is not required. 
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17.6.2 Invalid frame content 


There are two EOF delimiters which indicate that 
the frame contents are invalid. If a frame is 
received at an intermediate Fabric F_Port or an 
intermediate N Port and an error is detected 
within the frame, the frame is passed to the des- 
tination N Port with a modified EOF to indicate 
that an error was previously detected. Errors 
such as code violation or CRC errors are exam- 
ples of detectable frame errors. The following 
EOF delimiters indicate that the frame contents 
are invalid. 


17.6.2.1 End_of_Frame 
Disconnect_Terminate_Invalid (EOFdti) 


The EOFdti shall replace an EOFat delimiter 
on a frame with invalid frame content. The 
EOFadti shall remove a Class 1 Dedicated 
Connection through a Fabric, if present. It 
shall also indicate that all Sequences asso- 
ciated with the Connected N Port are 
abnormally terminated and may require 
sequence recovery (FC-4 protocol 
dependent). 7 


The frame containing the EOFdti is proc- 
essed in the following manner: 


1. no response frame is transmitted, 

2. the frame content may or may not be 
used at the receiver’s discretion, and 

3. the receiver knows that the Dedicated 
Connection has been removed. 


17.6.2.2 End_of_Frame Invalid (EOFni) 


The EOFni shall replace an EOFn, or EOFt 
indicating that the frame content is invalid. 


The frame containing the EOFni is proc- 
essed in the following manner: 


1. no response frame is transmitted, and 
2. the frame content may or may not be 
used at the receiver’s discretion. 


17.6.3 Aborted frame content 


17.6.3.1 End_of_Frame Abort (EOFa) 


The EOFa shall terminate a partial frame 
due to a malfunction in a link facility during 
transmission. The frame shall end on a 
word boundary and shall be discarded by 
the receiver without reply. The transmitter 
shall retransmit the aborted frame with the 
same Sequence count (SEQ CNT) up to its 
ability to retry, which may be zero. 


An invalid EOF (EOFati or EOFni) delimiter 
may be changed to an EOFa delimiter 
under the conditions specified for EOFa. 


EOFa delimiters shall not be changed to an 
invalid EOF delimiter under any conditions. 


17.7 Frame validity 


An FC-2 frame shall be considered “valid” if it 
contains a valid SOF, a valid EOF, valid data 
characters, and proper CRC verification of the 
Frame Header and Data Field. If a received 
frame is invalid, it may be discarded and no 
response frame or acknowledgment frame shall 
be transmitted. However, the R_RDY Primitive is 
transmitted in response to an appropriate frame 
regardless of Frame Content validity. The 


FC-PH REV 2.1, May 25, 1991 


detected error shall be accumulated in a Link 
Error Status Block. Frame reception is dis- 
cussed in 29.10. 


17.8 Frame field order 


The Frame Content is transmitted sequentially 
following the SOF delimiter and proceeds char- 
acter by character from left to right within the 
definition of the frame until the EOF delimiter is 
transmitted. Each field within the Frame Content 
is transmitted character by character from left to 
right. 


17.9 Fabric_Frame 


A Fabric Frame is a special frame format which 
is different than an FC-2 frame and is used by 
the Fabric for intrafabric communication. A 
Fabric Frame is composed of a SOFf delimiter, 
Frame Content, and an EOFn delimiter. If a 
Fabric Frame is received by an N Port, it shall 
be discarded and ignored. 


17.9.1 Fabric_Frame Content 


The Fabric Frame Content is not defined within 
the FC-2 document. 
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18 Frame_Header 


18.1 Introduction 


The Frame Header shall be subdivided into 
fields as shown in figure 35. | 


Word Bits 


‘fam [ee 
: 
: 
sau [om [eer 
ce 
5 | Parameters 


Figure 35. Frame_Header 


The Frame_Header shall be the first field of the 
Frame Content and immediately follow the SOF 
delimiter for all frames. The Frame Header 
shall be transmitted on a word boundary. The 
Frame_Header is used to control link operations, 
control device protocol transfers, and detect 
sequence errors in the link transport facility. 


18.1.1 Frame identification 


Identification fields such as OX_ID, RX_ID, and 
SEQ ID are provided for frame tracking, error 
detection, and frame processing. Frames are 
tracked through uniqueness of those fields from 
the time of assignment over the life of the field 
constructs. 


An Exchange Originator tracks frames on the 
basis of OX_ID|ISEQ IDIISEQ CNT. An Exchange 
Responder tracks frames on the basis of 
RX_ID|ISEQ_ID|ISEQ_ CNT. 


A given N_Port Originator may choose to provide 
frame tracking outside of FC-2. This is indicated 
by setting the OX_ID to hexadecimal ’FFFF’ with 
the New X_ID F_CTL bit = 1. This implies that 
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the Exchange Originator shall only have one 
Exchange active with a given destination N_ Port. 
If an N Port chooses a mechanism outside of 
FC-2, it is still responsible for providing proper 


SEQ ID and SEQ CNT values. In addition, it 
shall return the RX_ID assigned by the 
Responder. 


A given N_ Port Responder may choose to 
provide frame tracking outside of FC-2. This is 
indicated by setting the RX_ID to hexadecimal 
‘FFFF’ with the New X_ID F_CTL bit = 1. If an 
N Port chooses a mechanism outside of FC-2, it 
is still responsible for providing proper SEQ ID 
and SEQ CNT values. In addition, it shall return 
the OX_ID assigned by the Originator. 


The following sections describe the contents of 
the Frame_Header fields: 


18.2 R_CTL field 


Routing Control (Word 0, Bits 31-24) is a one 
byte field that contains control Bits to assist in 
frame routing, data routing, or addressing. 


¢ Bits 31-30 - DL Bits 


00 - Device Data frame 

O 1 - Reserved 

1 0 -- Link_Data frame 

1 1 - Link_Control frame 

DL bits differentiate device and link frames for 
routing purposes within an N_ Port or F_Port. 


When the DL Bits (Word 0, Bits 31-30) are set to 
zeros, it indicates a Device_Data frame. 


The DL Bits (Word 0, Bits 31-30) indicate a Link 
frame when Bit 31 is set to a one. Bit 30 further 
distinguishes between Link_Data and 
Link_Control frames. See clause 20 for a dis- 
cussion of Data and Link_Control frames. See 
clause 21 for a discussion on Link Application 
(Link_Data) frames. 


¢ Bits 29-24 - Data Category 


Category bits are available to each FC-4 to 
indicate data type or data control information 
relating to the data within the Payload 
portion of the Data Field. This information 


may assist the receiver of the Data frame in 
buffer management or routing based on data 
type. Category Bits shall specify a Data cat- 
egory for the Data Field of a single frame. 
Consecutive frames within a Sequence may 
contain different Categories of Data. 


18.3 Address identifiers 


Each N_Port shall have a single native address 
identifier which is unique within the address 
domain of a Fabric. In addition, an N_ Port may 
optionally have one or more alias addresses 
which may be shared across multiple N_ Ports 
within a node or common controlling entity. 
Alias addressing may be used to implement a 
Hunt Group. 


An N Port address identifier of binary zeros indi- 
cates that the N Port is unidentified. Address 
identifiers in the range of hexadecimal ’FFFFFO’ 
to ‘FFFFFE’ are well-known and reserved for 
Fabric use. See table 26. The Address identifier 
of hexadecimal ’FFFFFF’ is reserved. See clause 
23 for more information on address identifier 
assignment. 


Table 26. Fabric Address Identifiers 
Address Value 


FFFFFO to 
FFFFF9 


FFFFFA 
FFFFFB 
FFFFFC 
FFFFFD 
FFFFFE 


Description 


Reserved 


Management Server 
Time Server 

Name Server 

Fabric Controller 


Fabric F_Port 


18.3.1 Destination_ID (D_ID) 


The Destination Identification (D_ID) is a three 
byte field (Word 0, Bits 23-0) that contains the 
address identifier of an N_ Port within the desti- 
nation node. 


18.3.2 Source _ID (S_ID) 


The Source Identification (S_ID) is a three byte 
field (Word 1, Bits 23-0) that contains the address 
identifier of an N_Port within the source node. 
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18.4 Data structure type (TYPE) 


The data structure type (TYPE) is a one byte field 
(Word 2, Bits 31-24) that identifies the Upper 


Level Protoco! of the frame content for data 
frames. 
When the DL bits in R_CTL indicate a 


Link_Control frame, the TYPE field is decoded as 
a Link_Control command as specified in 20.3.1. 


When the DL bits in R_CTL indicate Link_Data or 
Device Data, the TYPE codes are decoded as 
shown in table 27. 


Table 27. TYPE codes 


Wd 2, bits 31-24 


0000 1101 
Reserved 


to 
Vendor Specific 


1100 1111 


1101 0000 
to 
1111 1111 


18.5 Frame Control (F_CTL) 


The Frame Control (F_CTL) field (Word 2, Bits 
23-0) is a three byte field that contains control 
information relating to the frame content. The 
format of the F_CTL field is defined in table 28. 
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Table 28 (Page 1 of 2). F_CTL field 


Word 2, 
Bits 


Refer- 
ence 


Control Field Description 


Exchange/Sequence 23-13 | 
Control 
0 = Originator of Exchange see 
exchange context | 1 = Responder of Exchange 24.3.1 
0 = Sequence Initiator see 
Sequence copter | 1 = Sequence Recipient 24.5.1 
Finck Senuanee O14 0 = intermediate or last Sequence of Exchange see 
"64 1 = first Sequence of Exchange 24.3.1 
Last Sequence 20 0 = first or intermediate Sequence of Exchange saepAs 
= 1 = last Sequence of Exchange 
End Sequence 0 = first or intermediate Data frame of Sequence see 24.7 
= 1 = last Data frame of Sequence 
‘ 0 = Connection active see 
| Endconnecton = | 8 1 = End of Connection Pending (Class 1) | 28.6.2 
Ben ecctine eoeaueka 17 0 = Connection Resource Required see 
> 1 = Connection Resource Not Required (Class 1) 28.6.1 
Sequence Initiative 16 pe NO edUCnee mee see 24.7 
1 = transfer Sequence Initiative 
new X_ID assigned 15 ieee i si aa aUretanes see 24.4 
- 1 = new X_ID assigned 
Invalidate X_ID 14 Os a es vlgnmentretainee see 24.4 
= {1 = invalidate X_ID | 


Reserved 13-6 


ACK frame - Sequence Recipient 
00 Continue Sequence 

01 Abort Sequence, retransmit 
10 Stop Sequence, read Status 
11 Sequence timeout 


Abort Sequence 


Condition see 24.7 


Data frame - Sequence Initiator 
00 Defer to Recipient 

01 Discard policy required 

10 Reserved 

11 Reserved 


<7] 
40) 


Exchange reassembly 2 


0 = Exchange reassembly not active 
1 = Exchange reassembly active 26.3.2 


End of Data field - bytes of fill 


00 OO Bytes of fill 
Fill Data Bytes 01 1 Byte of fill 

10 2 Bytes of fill 

11 3 Bytes of fill 


Bit 23 - Exchange Context indicates whether the S_ID is associated 


An Exchange is started by the Originator with the Originator or Responder. 


facility within an N_ Port. The destination Bit 22 - Sequence Context 
N Port of the Exchange is known as the 


Responder. Each frame for this Exchange A Sequence is started by a Sequence Initi- 


ator facility within an N_ Port. The destina- 
tion N_ Port of the Sequence is known as 


the Sequence Recipient. Each frame of the 
Sequence indicates whether the S_ID is 
associated with the Sequence Initiator or 
the Sequence Recipient. 


NOTE: Ownership is required for proper 
handling of Link_Control frames received in 
response to Data frame transmission. 
When a Busy frame is received, it may be 
in response to a Data frame (Sequence Ini- 
tiator) or to an ACK frame (Sequence 
Recipient). This Bit simplifies the neces- 
sary constructs to distinguish between the 
two cases. 


Bit 21 - First_Sequence 


This Bit is set to one on all Data frames in 
the First Sequence of an Exchange. It is 
set to zero for all other Sequences within 
an Exchange. 


Bit 20 - Last_Sequence 


This Bit is set to one on all Data frames in 
the Last Sequence of an Exchange. It is 
set to zero for all other Sequences within 
an Exchange. 


Bit 19 - End_Sequence 


This Bit is set to one on the last Data frame 
of a Sequence. This indication is used for 
Sequence termination by the two N_ Ports 
involved in the Sequence. This Bit is set to 
zero for the first or intermediate frames 
within a Sequence. 


Bit 18 - End_Connection 


This Bit is set to one to indicate that the 
N Port transmitting E_C is beginning the 
disconnect procedure. The N Port trans- 
mitting E_C set to one is completing its last 
Sequence of the Connection and_ is 
requesting the receiving N_Port to transmit 
a frame terminated by EOFat if the 
receiving N_ Port has completed all active 
Sequences. If the receiving N_ Port is not 
able to transmit EOFat, EC set to one 
requests that the N Port complete all 
active Sequences and not initiate any new 
Sequences during the current Connection. 


See 28.6.2 for a discussion on removing 
Class 1 Dedicated Connections (E_C bit). 
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Bit 17 Connection_Resource (C_R bit) 


The C_R bit is an information bit set by the 
Sequence Initiator on the first and the last 
frame of a Sequence. When the C_R bit = 
0, it indicates that Dedicated Connection 
resources are required by the Initiator in 
the Recipient N Port. When the C_R bit = 
1, it indicates that Dedicated Connection 
resources other than the current Sequence 
are no longer required and the Initiator is 
preparing to begin the disconnect proce- 
dure. The Sequence Initiator may reset the 
C_R bit to O after it has transmitted C_R = 
1 based on the current conditions in the 
N Port. The setting of C_R is not binding 
and either N_ Port may initiate the discon- 
nect procedure by setting E C = 1 regard- 
less of the C_R setting. 


Bit 16 - Sequence Initiative 


The Originator of an Exchange initiates the 
first Sequence as the Sequence Initiator. If 
the Sequence Initiative Bit is set to zero, 
the Sequence Initiator holds the initiative to 
continue transmitting the current Sequence 
in addition to the initiative to start new 
Sequences for this Exchange. The 
sequence Recipient gains the initiative to 
transmit a new Sequence for this Exchange 
after the Sequence Initiative has been 
transferred to the Recipient. This is 
accomplished by setting the Sequence Initi- 
ative to one in the last Data frame of a 
Sequence (End Sequence = 1). 


Bit 15 - New X_ID assigned 


This bit is set to one on a Data frame 
transmitted by the Sequence Initiator to 
indicate that its X_ID is new. New_X_ID is 
indicated at the beginning of an Exchange 
or following an X_ID reassignment transi- 
tion. The bit continues to be set to one for 
each frame of the Sequence or until the 
ACK is received when X_ID transition inter- 
lock is active. 


This bit is set to one on an ACK frame 
transmitted by the Sequence Recipient to 
indicate that its X_ID is new. New_X_ID is 
indicated at the beginning of an Exchange 
or following an X_ID reassignment transi- 
tion. The bit continues to be set to one for 
each frame of the Sequence or the ACK is 
transmitted when X_ID transition interlock 
is active. | 
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If X_ID interlock is active, Bit 15 is only 
used on the frame(s) in which the new X_ID 
is assigned. The new X_ID may be any 
value including the previous value speci- 
fied. If Bit 15 is set to zero, it indicates that 
the current X_ID assignment is valid. 


Bit 14 - Invalidate X_ID 


invalidate X_ID may be indicated by the 
Sequence Initiator in the last Data frame of 
a Sequence (End Sequence = 1) if the Ini- 
tiator has indicated X_ID reassignment is 
required during Login. When the Sequence 
Initiator indicates that the current X_ID its 
being invalidated or unassigned, the 
Sequence Recipient may also unassign its 
X_ID by setting Bit 14 to 1 in the ACK frame 
corresponding to the last Data frame of the 
Sequence. X_ID invalidation shall occur at 
the end of a Sequence but does not require 
transfer of Sequence Initiative at the same 
time. 


X_ID invalidation by an N_Port requires use 
of an Association Header as described in 
24.4. 


Bits 5-4 Abort Sequence Condition 
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Bits 5-4 are set to a value other than zeros 
by the Sequence Initiator on the first frame 
of an Exchange to indicate that the Origi- 
nator is requiring a specific error policy on 
this Exchange. 


00 Defer to Recipient 

0 1 Discard policy required 

10 reserved 

11 reserved 

Bits 5-4 are set to a value other than zeros 
by the Sequence Recipient in an ACK or 
Link Response frame to indicate to the 
Sequence Initiator that a malfunction or 
error has been detected by the Sequence 
Recipient. 


0 0 Continue Sequence 

0 1 Abort Sequence and retransmit 
10 Stop Sequence and read status 
1 1 Sequence timeout by Recipient 


An aborted Sequence is a Sequence which 
has been terminated in a manner other 
than the normal termination process. 


A setting of 0 1 indicates a request by the 
Sequence Recipient to the Sequence Initi- 
ator to terminate this Sequence using the 


Abort Sequence Protocol and_ then 
retransmit the Sequence. 


A setting of 1 0 indicates a request by the 
sequence Recipient to the Sequence Initi- 
ator to stop this Sequence using the Abort 
Sequence Protocol and then read FC-4 
status. This allows for an early termination 
by the Sequence Recipient. Some of the 
data received may have been processed. 
See 21.4.4 for a description of the Abort 
sequence protocol. 


A setting of 1 1 indicates that the Sequence 
Recipient has aborted the Sequence due to 
Sequence timeout (See 24.6.1). The 
sequence status is saved by the Sequence 
Recipient in the Exchange Status Block 
associated with the aborted SEQ _ID. 


Bit 2 - Exchange reassembly 


The Sequence Initiator shall set bit 2 = 0 
to indicate that the Payload in this Data 
frame is associated with an Exchange 
between a single pair of N Ports. There- 
fore, reassembly is confined to a single 
destination N_ Port. 


The Sequence Initiator shall set bit 2 = 1 
to indicate that the Payload in this Data 
frame is associated with an Exchange 
being managed by a single controlling 
entity using multiple N Ports at either the 
source, destination, or both. Therefore, 
segmentation and reassembly may be dis- 
tributed across multiple N Ports. (See 
26.3.2.) 


Bits 1-0 - Fill Data Bytes 


The Bits associated with the Fill Data Bytes 
notifies the Data frame receiver that one or 
more of the last three bytes of the Data 
Field do not contain data specified by the 
transmitter and shall be ignored. The fill 
character is not specified by the Standard 
but shall be a valid data character. 


18.6 Sequence_ID (SEQ _ID) 


The SEQ ID is a one byte field (Word 3, Bits 
31-24) that is assigned by the Sequence Initiator 
and shall be unique for a specific D_ID and S_ID 
at the time it is assigned. Both the Sequence 
Initiator and the Sequence Recipient track the 
status of the Sequence. The Sequence Initiator 
tracks the Sequence on the basis of OX_ID and 
SEQ ID. The Sequence Recipient tracks the 


Sequence on the basis of RX_ID and SEQ _ID. 
(See 18.9.) 


The combination of Initiator and Recipient 
Sequence Status Blocks identified by a single 
SEQ ID describe the complete status of that 
Data Sequence for a given Exchange. See 
clause 29 for a description of the Sequence 
Status Block. 


18.7 DF_CTL 


The Data Field Control (DF_CTL) is a one byte 
field (Word 3, Bits 23-16) that specifies the pres- 
ence of optional headers at the beginning of the 
Data_ Field. Control Bit usage is shown in table 
29. 


Table 29. DF_CTL Bit definition 


Word 
3, Optional Header 
Bit(s) 


23 Reserved for expansion 


20 0 - No Expiration Security Header 
1 - Expiration Security Header 


0 - No Network_Header 
1 - Network_Header 


0 - No Association Header 
1 - Association_Header 


is 
a) 


0 - No Operation_Header 
1 - Operation _Header 


| Reeves 


00 -No Device_Header 
01 -16 Byte Device_Header 


10 -32 Byte Device_Header 
11 -64 Byte Device_Header 


The Optional Headers are positioned in the Data 
Field in the sequence specified with the Bit 23 
header as the first header in the Data Field, Bit 
22 header as the second header in the Data 
Field, and so forth, in a left to right manner cor- 
responding to Bits 23, 22, 21, and so forth. 


If either Bit 17 or 16 is set to one, then a Device 
Header is present. The size of the Device 
Header is specified by the encoded value of Bits 
17 and 16 as shown. 


If an Optional Header is not present, no space in 
the Data Field is reserved. Therefore, for 
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example, if Bits 23 and 22 are zero and Bit 21 is 
one, the first data byte of the Data Field contains 
the first byte of the Network_Header. 


See clause 19 for a discussion on Optional 
Headers. 


18.8 Sequence Count (SEQ_CNT) 


The sequence count (SEQ CNT) is a two byte 
field (Word 3, Bits 15-0) that shall indicate the 
sequential order of frame transmission within a 
single Data frame Sequence. The first frame of 
a Sequence shall contain a sequence count of 
binary zero. If back to back Sequences for the 
same Exchange occur, it is the responsibility of 
the Sequence Initiator to use a unique SEQ ID 
since frame uniqueness is  based-= on 
X_IDIISEQ_IDJISEQ CNT. The sequence count 
shall be incremented by one on all subsequent 
Data frames within this Sequence. ACK and 
Link Response frames shall be identified by the 
same SEQ ID and SEQ CNT as the frame to 
which it is responding. Frames are tracked on a 
SEQ IDSEQ CNT basis associated with the 
OX_ID for the Originator and the RX_ID for the 
Responder. 


The sequence count shall wrap to zero after 
reaching a value of 65535. Sequences of Data 
frames and sequence count values are dis- 
cussed in clause 24. 


18.9 Originator Exchange_ID (OX_ID) 


The Originator Exchange ID is a two byte field 
(Word 4, Bits 31-16) that identifies the 
Exchange ID assigned by the Originator of the 
Exchange. The Originator of the Exchange shall 
assign a unique value for OX_ID, if used, or a 
value of hexadecimal ‘FFFF’ if not used. An 
OX_ID of hexadecimal ‘’FFFF’ indicates that 
uniqueness is not being enforced by the Origi- 
nator by the OX_ID mechanism. 


An Originator Exchange Status Block associated 
with the OX_ID is used to track the progress of a 
series of Sequences which composes. an 
Exchange. See clause 24 for a discussion of 
Sequences and Exchanges. 


NOTE - If hexadecimal ’FFFF’ is used as the 
OX_ID, then the Originator uses an alternate 
tracking mechanism. If the OX_ID is unique, it 
may be used as an index into a control block 
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structure which may be used in conjunction with 
other constructs to track frames. 


18.10 Responder Exchange_!ID 
(RX_ID) 


The Responder Exchange _ID is a two byte field 
(Word 4, Bits 15-0) assigned by the Responder 
which provides a unique, locally meaningful 
identifier at the Responder for an Exchange 
established by an Originator and identified by an 
OX _ID. 


A Responder Exchange Status Block associated 
with the RX_ID is used to track the progress of a 
series of Sequences which composes an 
Exchange. See clause 24 for a discussion of 
sequences and Exchanges. 
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18.11 Parameters 


The Parameter field (Word 5, Bits 31-0) has two 
meanings based on frame __ type. For 
Link_Control frames, the Parameter field is used 
to carry data specific to the Link_Control frame. 


For Data frames, the Parameter field specifies 
Relative Offset, a four-byte field that specifies 
the relative displacement of the first byte of the 
Payload of the frame from the base address. 
Relative Offset is specified in terms of bytes. 


The offset value may be relative to one or more 
Sequences within an Exchange. The number of 
bytes transmitted in a single Sequence shall not 
exceed the maximum value of the Relative Offset 
(Parameter) field ( 232 - 1 ). <A value of 
hexadecimal ’FFFFFFFF’ indicates that this field 
shall be ignored. Performance may be improved 
if data is aligned on natural boundaries. 


see clause 26 for a discussion concerning Rela- 
tive Offset. See clause 20 for a discussion con- 
cerning use of the Parameter field in 
Link_Control frames. 


19 Optional headers 


19.1 Introduction 
Five optional headers defined within the Data 
Field of a frame are: 


1. Extended Frame_Header 

2. Expiration Security_Header 
3. Network _Header 

4. Association Header 

5. Operation Header 


The presence of optional headers is defined by 
control Bits in the DF_CTL field of the 
Frame Header. The sequential order of the 
optional headers, Device Header and Payload 
and their sizes are indicated in figure 36. 


Start_of Frame 4 bytes 
| Extended Frame Header 
| (optional) 
Expiration Security Header | 16 bytes 
(optional ) 
Network Header 16 bytes 
Data (optional) 
Field 
(9 to Association Header 16 bytes 
2112) (optional) 
Operation Header 16 bytes 
(optional) 
Device Header 16, 32 
or 64 bytes 
/ Payload / 9 to 2112 
/ / bytes 
CRC 4 bytes 
EOF 4 bytes 


Ma a) 


Figure 36. Optional headers order 
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If present, an Extended Frame Header shall be 
the first optional header to follow’. the 
Frame_Header. If present, an 
Expiration Security Header shall be the next 16 
bytes of the Data Field following the Extended 
Frame Header. If present, a Network Header 
shall be the next 16 bytes of the Data Field. If 
present, a Operation Header shall be the next 16 
bytes of the Data Field. If present, a 
Device_Header shall follow the optional headers. 
If none of the optional headers is present, no 
space in the Data Field shall be reserved. 


The Network Header may be used by a bridge or 
a gateway node which interfaces to an external 
Network. The Network Header, if present, shall 
be 16 bytes in size. 


The Operation Header is used for correlating 
multiple exchanges within a given Operation. 
This header may also be used for striping of 
data across multiple N Ports within a_ single 
node. The Operation Header, if present, shall 
be 16 bytes in size. 


The Device_Header, if present, shall be 16, 32, or 
64 bytes in size. The contents of the Device 
Header are entirely under the control of a level 
above FC-2 based on the TYPE field. 


19.2 Extended Frame_Header 


The Extended Frame Header shall provide the 
capability to extend the Frame Header functions 
for future needs. Its presence shall be indicated 
by Bit 23 in the DF_CTL field, located in the 
Frame Header, being set to one. The Extended 
Frame_Header is reserved for future expansion. 


19.3 Expiration _Security_Header 


The Expiration Security Header, as shown in 
figure 37, is an optional header within the 
Data_Field content. Its presence shall be indi- 
cated by Bit 22 in the DF_CTL field, located in 
the Frame_Header, being set to one. The 
Expiration Security Header shall be 16 bytes in 
size. 
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Word 
0 Expiration Time - 
(Most significant word) 
+++ 
1 Expiration Time 
(Least significant word) 
+ 
31 24 15 
2 S Type |Reserved S_Length 


+} 


3 Security 


Figure 37. Expiration_Security_Header 


19.3.1 Expiration Time 


An Expiration Timer in a system shall be used to 
compute the Expiration Time to be included in 
this field. The Expiration Timer shall be a 64-bit 
fixed-point number based, in seconds relative to 
0000 UT on 1 January 1900. The integer part of 
the number shall be the most significant 32 bits, 
and the fractional part shall be the least signif- 
icant 32 bits. | 


On start up, a value of zeros shall be used to 
indicate an invalid or undefined time. When an 
N_ Port begins communication within a system, it 
may obtain the Expiration Timer value from the 
Fabric or other specified N Port. The Expiration 
Time shall be determined by adding an expira- 
tion time value to the current system Expiration 
Timer value. If a frame is received after the 
Expiration Time has been exceeded, the frame 
shall be discarded by the N_Port. The frame may 
be discarded by the Fabric. 


In a network of heterogeneous Fabrics, the start 
date of 1 January 1900 shall be used. For local 
use, the fractional part of the timer shall be 
optional. Multiple Fabrics in a system shall syn- 
chronize their Expiration Timers to an accuracy 
of + 2 secs. 
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19.3.2 Security type (S_Type) 


The field indicates the type of Security sup- 


ported. 


19.3.3 Security length (S_Length) 


The field indicates the length in bytes of the 
security information. 


19.4 Network_Header 


The Network_Header, as shown if figure 38, is an 
optional header within the Data Field content. 
Its presence shall be indicated by Bit 21 in the 
DF CTL field, located in the Frame_Header, 
being set to one. The Network Header shall be 
16 bytes in size. 


32 
0 i Network Destination_ID 
high order bits) 
++ 


1 Network Destination_ID 
(low order bits) 


2 Network _Source_ID 
(high order bits) 
—————+ 


3 | Network Source_ID 
(low order bits) 


Figure 38. Network_Header 


The Network_Header provides information to an 
N_ Port for traversing a heterogeneous network. 


19.4.1 D_NAA or S_NAA 


Destination Network_Address_ Authority (D_NAA) 
or Source Network_Address Authority (S_NAA) 
field indicates the authority responsible for the 
administration of the network address (destina- 
tion or source) used. The following are Network- 
_Address_ Authority (NAA) indicators: 


Table 30. NAA identifiers 


19.4.2 Network_Destination_ID or 
Network_Source_!ID 


The  Network_Destination ID or  Network- 
_Source_ID shall be a 60 bit field indicating the 
network address being used. These network 
addressed are also referred to as 
World Wide Names. 


19.4.2.1 IEEE 48-bit address 


When D_NAA (or S_NAA) is IEEE, Network_Desti- 
nation ID (or Network _Source_ID) field will 
contain a 48-bit IEEE Standard 802.1A Universal 
LAN MAC Address (ULA). The ULA shall be 
represented as an ordered string of six bytes 
numbered from O to 5. The least significant bit 
of byte 0 shall be the Individual/Group Address 
(I/G) bit. The next least significant bit shall be 


the Universally or Locally Administered Address | 


(U/L) bit. This IEEE Standard 802.1A further spec- 
ifies that the bytes be transferred in the order 0 
to 5. Figure 39 shows how the bytes of an ULA 
shall be mapped to two words on the Network 
Header. 


Bits 


3 2 | 0 
MEET TET PIP PPP P EP ist bit rr tbh rrr 


ULA Byte 0 {/ 
L|G 


ULA Byte 3 ULA Byte 4 


ULA Byte 2 


MSW - Most significant word 
LSW - Least significant word 


Figure 39. IEEE 48-bit address format 
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19.4.2.2 CCITT 60-bit address 


When D_NAA (or S_NAA) is CCITT, Network- 
_Destination_ID (or Network _Source_!D) field will 
contain a 60-bit CCITT standard address. 


19.5 Association_Header 


The Association Header is an optional header 
within the Data Field content. Its presence shall 
be indicated by Bit 20 in the DF CTL field, 
located in the Frame_Header, being set to one. 
The Association Header shall be 32 bytes in 
size. 


Bits 
Word 
63 32 
0 Originator Process Associator 
(most significant word) 
+—_______- +--+ 
31 0 
] Originator Process Associator 
(least significant word) 
+++ 7 
63 32 
2 Originator Operation Associator | 
(most significant word) 
$$$} 
31 0 
3 Originator Operation Associator 
(least significant word) 
——____—__+—_____-+ 
63 32 
4 Responder Process Associator 
| (most significant word) 
+--+ 
31 0 
9 Responder Process Associator 
(least significant word) 
$+ 
63 | 32 
6 Responder Operation Associator 
(most significant word) 
+--+ 
31 0 
] Responder Operation Associator 
(least significant word) 


Figure 40. Association _Header 


The Association Header shall be used to track 
an Exchange when an X_ID is reassigned during 
the Exchange (see 24.4). The 
Association Header shall be subdivided into four 
fields as illustrated in figure 40. Contents of 
Association Header are meaningful to the Node 
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which generates it. It may not be meaningful to 
the other Node receiving it. 


19.5.1 Process _Associators 


Process Associators (Originator and Responder) 
have following characteristics: 


— The Process Associators shall be known by 
each end prior to the initiation of an Opera- 
tion between the two processes. 

— The Process Associators shall be remem- 
bered for the duration of the process life. 

— The Process Associators may not change 
between Operations. 


19.5.2 Operation_Associators 


Operation_Associators (Originator and 
Responder) have following characteristics: 


— The Operation _Associators shall be remem- 
bered for the duration of the Operation. 

— The Operation Associators may not change 
within an Operation. 


19.6 Operation Header 


The Operation Header is an optional header 
within the Data_Field content. Its presence shall 
be indicated by Bit 19 in the DF_CTL field, 
located in the Frame_Header, being set to one. 
The Operation_Header shall be 16 bytes in size. 


Bits 
Word 
63 32 
0 Operation Identifier 
(0 ID) 
++ 
31 0 
1 Operation Identifier 
(0 ID) 
+ 
31 16 Q 
2 Operation Reserved 
Control (0_CTL) 
ie 
31 0 
3 Reserved 


Da Ne a ee ed 


Figure 41. Operation_Header 
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An Operation is a group of one or more related 
Exchanges. The Operation Header contains 
information which shall correlate one or more 
Exchanges within a single Operation specified by 
the TYPE field specified (ie., FC-4). 


The Operation Header shall be subdivided into 


four fields as illustrated in figure 41. The 
Operation Header format shall be common to all 
Upper Level Protocols using the 


Operation Header. 


19.6.1 Operation_Identifier 


The Operation_Identifier (O_ID) shall be an eight- 
byte field specified by the system which owns or 
initiates the first exchange of this operation. The 
OID shall correlate one or more exchanges 
within a single operation. The O_ID is inter- 
preted by the owner FC-4. 


19.6.2 Operation_Control 


Operation Control (O_CTL) shall be a two-byte 
field containing general control information 
common to FC-4s. The format shall be as speci- 
fied in figure 42. 


Figure 42. O CTL field 


¢ Bit 15 - Operation Context | 

— 0 = specifies that this frame is 
transmitted by the N Port (node) 
which initiated this Operation. 

— 1 = specifies that this frame is 
transmitted by the N Port (node) 
which is the Operation Recipient. 


«Bit 14 - first OpHdr in Operation 

Bit 14 = 1 indicates that this is the first 
Operation Header in an operation. This 
Bit shall be set to 0 for all other frames. 


¢ Bit 13 - last OpHdr in Operation 

Bit 13 = 1 indicates that this is the last 
Operation Header in this operation. This 
Bit shall be set to O for all other frames. 


« Bits 12-0 - Reserved 


19.7 Device_Header 


A Device Header shall be a 16, 32, or 64 byte 
field. The content of the this Header shall be 
specified by FC-4 based on the TYPE field speci- 
fied. 
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20 Data and Link_Control frames 


20.1 Introduction 
There are two categories of frames and a Primi- 
tive Signal: 


— Data (Link Data, Device Data) frames, and 
— Link_Control (ACK, Link_Response) frames. 
— R_RDY Primitive Signal. 


Data frames convey information from a source 
N_ Port to destination N Port. Data frames may 
or may not contain Payload in the Data Field fol- 
lowing the Frame_Header. A variety of Protocols 
using Data frame Sequences may be employed. 
An example of a Request-Reply protocol for Link 
Applications is discussed in clause 21. 


Link_Control frames are individual Link-Level 
frames which indicate successful or wunsuc- 
cessful frame delivery and _ participate’ in 
end-to-end flow control. Successful delivery is 
indicated by ACK frames, while unsuccessful 
delivery is indicated by Link_Response frames. 


The R_RDY Primitive Signal is used for buffer to 
buffer flow control which is discussed in clause 
25. 


20.1.1 R_RDY response 


In Class 1, a connect-request (SOFc1) frame is 
responded to by transmitting the R_RDY Primi- 
tive Signal. In Class 2 and Class 3, all frames 
received (ie., both Data frames and Link_Control 
frames) are responded to by transmitting the 
R_RDY Primitive Signal. 


20.1.2 Data frame responses 


Link_Control response frames are ACK frames 
(ACK_1 and ACK_N) and Link_Response frames 
(P_BSY, P_RJT, F_BSY, and F RJT). 
Link_Control responses to Data frames are class 
dependent. 
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20.1.2.1 ACK frames 


Successful Data frame delivery 


° Class 1 
1. ACK_1, or 
2. ACK_N 

* Class 2 
1. ACK_1, or 
2. ACK_N 

¢ Class 3 
1. No response 


20.1.2.2 Link_Response frames 


Unsuccessful Data frame delivery 


° Class 1 
1. F_BSY (Fabric Busy), or 
2. P_BSY (N_Port Busy), or 
3. F_RJT (Fabric Reject), or 
4. P_RuT (N_ Port Reject). 

¢ Class 2 
1. F_BSY (Fabric Busy), or 
2. P_BSY (N_Port Busy), or 
3. F_RJT (Fabric Reject), or 
4. P_RJT (N_Port Reject). 

* Class 3 
1. No response 


20.2 Data frames 


Data frames are used to transfer information 
from a source N Port to a destination N_ Port. 
Device Data frames are identified by the DL Bits 
31-30 in the R_CTL field being set to 0 O and the 
TYPE field identifying a specific Upper Level Pro- 
tocol. 


Data frames may be used to transfer information 
such as data, control information, header infor- 
mation, and status as specified by upper levels. 
In Class 1 and 2, each Data frame successfully 
transmitted shall be acknowledged by an ACK 
frame to indicate successful delivery to the desti- 
nation N_ Port. An indication of unsuccessful 
delivery shall be returned to the transmitter by a 
Link Response frame in Class 1 and 2. 


Data frames may be streamed, i.e., multiple, 
unidirectional frames may be transmitted before 
a response frame is received. The number of 


outstanding, unacknowledged Data frames 
allowed is specified by a Service Parameter 
during the Login procedure (Credit). See clause 
23 for a discussion on Login and Service Param- 
eters and clause 25 for a discussion on flow 
control. 


Multiple, unidirectional Data frames are called a 
Sequence. See clause 24 for a discussion on 
Sequences and Exchanges. 


Delimiters: SOFci1, SOFix, SOFnx, EOFn, EOFt, 
EOF ct. 

Format: FT_1 

Addressing: The S_ID field designates the 


source N Port (Sequence Initiator) transmitting 
the Data frame. The D_ID field designates the 
destination N Port (Sequence Recipient) of the 
Data frame. 

Data Field: The Data Field for Data frames is 
variable in size but a multiple of four bytes. The 
Data Field may contain optional Headers whose 
presence is indicated by the DF_CTL field in the 
Frame_Header. (See clause 19.) 


In order to accommodate message content 
within the Data field that is not a multiple of four 
bytes, fill characters shall be appended to the 
end of the Data Field. The number of fill charac- 
ters is specified by F_CTL Bits 1-0. (See 18.5.) 
The fill character is not specified by the 
standard. 

Responses: 


R_RDY Primitive (SOFc1, SOFx2, SOFx3) 
ACK 

— ACK_1, or 

— ACK_N 

Link_Response 

— F_ RJT, P_RJT 

— F_BSY, P_BSY 


20.2.1 Transfer Mechanisms 


several mechanisms are available for a 
Sequence which allow an Upper Level Protocol 
to convey information to a destination N_ Port. 
Those mechanisms include: 


— Data category within R_CTL field 
— options within F_CTL field 
— Device Header 
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Data Category: 


The Data Category is included in R_CTL to assist 
the receiver of a Data frame in directing the 
Data Field content to the appropriate buffer pool. 


F_CTL field options: 


Within the F_CTL field, Exchange and Sequence 
CTL bits are used to manage the initiative to 
transmit Data frames, manage Sequences, and 
manage Exchanges. 


Device Header: 


Provisions have been made for a Device Header 
to precede the actual Data contained in the Data 
Field of a Data frame. The © size of the 
Device Header is encoded in the DF_CTL field of 
the Frame Header. This provides an additional 
means to specify unique protocol-dependent 
information to an Upper Level. 


20.3 Link_Control 


Link_Control frames are used by the N_ Port Link 
Facility functions to control frame transfer at the 
link level. 


Link Control frames are the only Frame_Type 0 
frames. In FT_O frames, the Parameter field is 
used to carry up to four bytes of information. 
FT O frames are identified by the DL Bits 31-30 in 
the R_CTL field being set to 1 1 for all 
Link_Control frames. 


Link_Control frames provide: 


— indication of successful delivery, 

— indication of unsuccessful delivery, 

-— flow control and buffer management 
feedback. 


An N_ Port shall be required to provide sufficient 
link control facilities such that Link _Control 
frames received in response to Data frames 
transmitted do not result in P_BSY response — 
frames. 


20.3.1 Link_Control command codes 
When DL Bits 31-30 in the R_CTL field are set to 


1 1, the TYPE field of the Frame Header is 
encoded as shown in table 31. 
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Table 31. Link Control codes 


Encoded 
wale Description 
Word 2, 
bits 31-24 


0000 0000 ACK_1 
Fabric Reject F RUT 


20.3.2 Link_Continue function 


ACK frames shall be sent in response to valid 
Data frames frames (see 17.7) to acknowledge 
end to end frame transfers. The R_RDY Primi- 
tive shall be sent in response to a single frame 
(see 17.7) to acknowledge a buffer to buffer 
frame transfer based on SOF delimiter. The fol- 
lowing list specifies flow control elements: 


— R_RDY - buffer to buffer flow control for 
frames between F_Ports and N_ Ports if a 
Fabric is present, or between N Ports 
without a Fabric present. The R_RDY 
Primitive is transmitted on receipt of any 
Class 2 or 3 frame as well as a Class 1 
connect-request frame. 


— ACK_1 - end to end flow control for a 
single Data frame transfer between 
N Ports with or without a _ Fabric 
present. The ACK_1 frame is transmitted 
on receipt of Class 1 or 2 Data frames. 


— ACK_N - end to end flow control for one 
or more consecutive Data frame trans- 
fers between N_ Ports with or without a 
Fabric present. The ACK_N frame is 
transmitted on receipt of Class 1 or 2 
Data frames. 


Either ACK_1 or ACK_N may be used for 
acknowledgment of Data frames between 
N_ Ports for a given active Sequence, but both 
forms shall not be used within the same 
Sequence. 
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- Addressing: 


20.3.2.1 Receiver Ready (R_RDY) 


The R_RDY Primitive shall indicate that a single 
frame was received and that the interface buffer 
which received the frame is available for further 
frame reception. The R_RDY Primitive provides 
buffer to buffer flow control for a single frame. 


R_RDY is transmitted between an N_ Port and an 
F Port with a Fabric present, or between two 
N Ports without a Fabric present for all Class 2 
and Class 3 frames and connect-request frames 
in Class 1. The R_RDY Primitive is not for- 
warded to any higher levels within an N_Port or 
passed beyond the entry or exit point of the 
Fabric. 


See 16.3.2 for specification of the number of 
Idles before and after the R_RDY Primitive 
during transmission. 

Responses: There is no response to an R_RDY 
Primitive. 


20.3.2.2 Acknowledge_1 (ACK_1) 


The ACK_1 frame shall indicate that a single 
valid Data frame was received by the destination 
N_ Port for the corresponding 
X_IDIISEQ IDJJSEQ CNT and that the interface 
buffer which received the frame is available for 
further frame reception. ACK_1 frames are used 
in Class 1 and 2. The ACK_1 frame provides 
end to end flow control for a single frame 
between two N_Ports. 


ACK_1 is not forwarded to any higher levels 
within an N_ Port. 

Delimiters: SOFnx, EOFn, EOFt, EOFat 

Format: FT_0 

The DID field designates the 
source of the Data frame (Sequence Initiator) 
being replied to by ACK_1, while the S_ID field 
designates the source of the ACK 1 frame 
(Sequence Recipient). 

F_CTL: The F_CTL field is returned with 
Sequence and Exchange Context Bits inverted in 
the ACK_1 frame. 

SEQ_ID: the SEQ _ID matches the SEQ _ID of the 
frame being replied to by ACK_1. 

SEQ _ CNT: The sequence count (SEQ CNT) shall 
be equal to the sequence count of the Data 
frame being replied to by the ACK_1. 

Parameter field: The field shall contain a binary 
one. 


Responses: 


R_RDY Primitive (SOFx2) 
Link_Response 

— F_RJT, P_RJT 

— F_BSY 


20.3.2.3 Acknowledge_N (ACK_N) 


The ACK_N frame shall indicate that one or 
more consecutive Data frames for the corre- 
sponding X_ID|ISEQ ID were received by the des- 
tination N_ Port. Buffers are available for 
reception of additional Data frames as noted in 
the credit acknowledged. The ACK_N frame pro- 
vides end to end flow control for one or more 
Data frames between two N Ports. Support for 
the ACK_N frame is optional and is specified in 
the Service Parameters during Login. 


A specific Data frame is allowed to be acknowl- 
edged once and only once. ACK_N is only used 
for Class 1 and Class 2 Data frames. (See 23.5) 


ACK_N is not forwarded to any higher levels 
within an N_Port. 

Delimiters: SOFnx, EOFt, EOFdt 

Format: FT_0 

Addressing: The D_ID field designates the 
source of the Data frame (Sequence Initiator) 
being replied to by ACK_N, while the S_ID field 
designates the source of the ACK_N frame 
(Sequence Recipient). 

F CTL: The F_CTL field is returned with the 


Sequence and Exchange Context Bits inverted in | 


the ACK_N frame. Parameters. (See clause 23.) 
SEQ_ID: The SEQ ID matches the SEQ _ID of the 
frames being acknowledged. 

SEQ_CNT: The SEQ CNT specifies the SEQ CNT 
of the highest Data frame being acknowledged. 
(See Annex M, “ACK_N Usage (Informative)” for 
examples of use.) 

Parameter field: Bits 31 - 16 are reserved. Bits 
15 - 0 contain the number of consecutive Data 
frames up to and including the frame identified 
by sequence count (SEQ CNT) of the ACK_N. 
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ACK_N parameter 


First Second Third Fourth 
Byte Byte Byte Byte 


3 2\2 ben al 
1 413 87615 817 y 
CECE COCR COCO Cece 


Credit 
Acknowledged (m) 


Bits 


Figure 43. ACK_N parameter 


Responses: 


R_RDY Primitive (SOF) 
Link _Response 

— F_RJT, P_RJT 

— F BSY 


NOTE - For example, if the SEQ CNT is 7 and the 
value of the Parameter field is 3, frames 5, 6, 
and 7 are being acknowledged. (See Annex M, 
“ACK_N Usage (Informative)” for examples of 
use.) 


20.3.3 Link_Response 


Link_Response frames shall be sent by either 
the destination N_Port or a Fabric F_Port in reply 
to frames for Class 1 and 2. Link_Response 
frames shall only be sent in reply to valid frames 
(see 17.7). 


A Link_Response indicates that the frame identi- 
fied by the SEQ ID and SEQ CNT was not deliv- 
ered to or processed by the destination N_ Port. 
When a Link_Response frame (either Reject or 
Busy) is generated by an F Port or a facility 
internal to the Fabric, the frame is routed to the 
destination N_ Port of the Link_Response frame. 


. Link_Response frames may be: 


— Busy - indicates a Busy condition was 
encountered in the Fabric or destination 
N_ Port. 


— Reject - indicates that delivery of the 
frame is being denied. 


| 
| 
| 


ON el eee 
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20.3.3.1 Reject (P_RUT, F_RuT) 


The Reject Link Response shall indicate that 
delivery of a frame is being denied. A four-byte 
reject action and reason code is contained in the 
Parameter field. Rejects are transmitted for a 
variety of conditions. For certain conditions retry 
is possible, whereas other conditions may 
require specific intervention. This standard does 
not define the specific intervention required. 


Reject Link Response frames are transmitted for 
Class 1 and 2 frames. In Class 3, the frame in 
question shall be discarded. A Reject frame 
(F_RJT, P_RJT) shall not be transmitted in 
response to another Reject frame (either F_ RJT 
or P_RJT). The Reject frame received in error 
shall be discarded. 


P_RJT: N_ Port Reject indicates that the Reject 
was issued by the destination N_ Port. 


F_RJT: Fabric Reject indicates that the Reject 
was issued by an F_Port within a Fabric. 


Delimiters: SOFnx, EOFt, EOFat 

Format: FT_0 

Addressing: The D_ID field designates the 
source of the frame being rejected while the 
SID field designates the destination of the 
frame being rejected. 

F CTL: The F_CTL field is returned with the 
Sequence and Exchange Context bits inverted in 
the F_RJT or P_RJT frame. 

SEQ_ID: The SEQ ID matches the SEQ _ID of the 
frame being rejected. 

SEQ CNT: The SEQ CNT shall be equal to the 
SEQ CNT of the frame being rejected. 

Parameter field: The four bytes of this field indi- 
cate the action code and reason for rejecting the 
request. (See figure 44 and tables 32 and 33.) 


Reject parameter 


Third 
Byte 


Fourth 
Byte 


Second 
Byte 


First 
Byte 


Bits 


Reason 


Action 


Figure 44. Reject code format 
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Vendor Unique 


Description 


Sequence terminated - retry 
after correction 


0000 0001 (1) 


Sequence terminated - non- 
retryable error 


0000 0010 (2) 
0000 0011 (3) 
0000 0100 (4 


Action 1 


Abort Sequence requested - 
retry after correction 


Abort Sequence requested - 
non-retryable error 


Action 1 indicates that the Recipient or the 
Fabric has abnormally terminated the 
Sequence (EOFt or EOFat). For a Class 1 
connect-request the reject frame is ended 
with EOFdt. The Recipient shall only termi- 
nate the Sequence on a Reject in response 
to a connect-request (SOFc1) or _ in 
response to an _ interlocked . Data frame 
associated with X_ID assignment or reas- 
signment. The Sequence is retryable if the 
corrective action indicated by the reason 
code is performed: 


— Class not supported 

— Invalid D_ID 

— Invalid S_ID 

— N Port not available-temporary 
— N Port not available-permanent 
— Login required 


Applicability: 


— by Fabric when D_ID = Fabric 
— by Fabric when D_ID = N_ Port 
— by N Port when D_ID = N Port 


Action 2 


Action 2 indicates that the Recipient or the 
Fabric has abnormally terminated the 
Sequence (EOFt or EOFat). For a Class 1 
connect-request the reject frame is ended 
with EOFdt. The Recipient shall only termi- 
nate the Sequence on a Reject in response 
to a connect-request (SOFc1) or in 
response to an interlocked Data frame 
associated with X_ID assignment or reas- 
signment. The Sequence is non-retryable | 
and further recovery such as_ Abort 


Exchange may be required. The following 
reason codes are non-retryable: 


— Delimiter usage error 
— Type not supported 

— Invalid Link_Control 
— Invalid R_CTL 

— Invalid F_CTL 

— Invalid OX_ID 

— Invalid RX_ID 

— Invalid SEQ ID 

— Invalid DF_CTL 

— Invalid SEQ CNT 

— Invalid Parameter field 
— Exchange error 

— Protocol error 

— Data Field too large 

— Unexpected ACK 

— Unexpected Link_Response 


Applicability: 


— by Fabric when D_ID = Fabric 
— by N Port when D_ID = N Port 


Action 3 


Action 3 indicates that the Recipient is 
requesting the source of the rejected frame 
to abort the Sequence. The Sequence is 
retryable if the corrective action indicated 
by the reason code is performed: 


— Class not supported 
— Invalid D_ID 

— Invalid S_ID 

— Login required 


Applicability: 


— by Fabric when D_ID = Fabric 
— by Fabric when D_ID = N_ Port 
— by N_Port when D_ID = N Port 


Action 4 


Action 4 indicates that the Recipient is 
requesting the source of the rejected frame 
to abort the Sequence or Exchange. The 
Sequence is non-retryable for the following 
reason codes: 


— Delimiter usage error 

— N Port not available, temporary 
— N Port not available, permanent 
— Type not supported 

— Invalid Link_Control 

— Invalid R_CTL 

— Invalid F_CTL 
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— Invalid OX_ID 

— Invalid RX_ID 

— Invalid SEQ ID 

— Invalid DF_ CTL 

— Invalid SEQ CNT 

— Invalid Parameter field 
— Exchange error 

— Protocol error 

— Data Field too large 

— Unexpected ACK © 
— Unexpected Link_Response 


Applicability: 


— by Fabric when D_ID = Fabric 
— by Fabric when D_ID = N Port 
— by N Port when D_ID = N Port 


Table 33 (Page 1 of 2). Reason Codes 


Wd 5, bits 23-16 


0000 1001 
0000 1011 


0010 0001 


0010 1101 
to 
1111 1110 


Description 


Class not supported 
Delimiter usage error 
Invalid D_ID 

Invalid S_ID 


N_Port not available, tempo- 
rary 


N_Port not available, perma- 
nent 


TYPE not supported 
Invalid Link_Control 
Invalid R_CTL field 
Invalid F_CTL field 
Invalid OX_ID 

Invalid RX_ID 

Invalid SEQ_ID 

Invalid DF_CTL 

Invalid SEQ CNT 
Invalid Parameter field 
Exchange Error 
Protocol Error 

Data Field too large 
Unexpected ACK 
Unexpected Link_Response 


Login Required 


Reserved 
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Table 33 (Page 2 of 2). Reason Codes 


Encoded Value Debetation 
Wd 5, bits 23-16 P 
| Vendor Unique Error 
(See Bits 7-0) 


Reject reason codes are arranged in descending 
priority as the encoded value increases. There- 
fore, if Class not supported is the reject reason, 
no additonal checking of the frame is required 
and no other errors are reported. The first error 
encountered according to the priority specified is 
the error reported and further error checking is 
not required. 


—4111«1111 


| Class not supported 


The Class of Service specified by the SOF 
delimiter of the frame being rejected is not 
supported. 


Delimiter usage error 


The SOF or EOF is not appropriate for the 
current conditions. For example, a frame 
started by SOFc1 is received while a Class 
1 Dedicated Connection already exists with 
the same N_Port. 


Invalid D_ID 


F RJT - the Fabric is unable to locate the 
destination N Port address. 


P RJT - the N Port which received this 
frame does not recognize the D_ID as its 
own Identifier. 


Invalid S_ID 


F RJT - the S_ID does not match the 
N_ Port Identifier assigned by the Fabric. 


P RJT - the destination N Port does not 
recognize the S_ID as valid. 


N_Port not available, temporary 


F_ RJT - The N_Port specified by the D_ID is 
a valid destination address but the N_Port 
is not functionally available. The N_ Port is 
online and may be performing a_ Link 
Failure or Recovery Protocol, for example. 


N_Port not available, permanent 


F RJT - The N Port specified by the D_ID is 
a valid destination address but the N_ Port 
is not functionally available. The N_Port is 
Offline or Powered Down. 
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TYPE not supported 


The TYPE field of the frame being rejected 
is. not supported by the N Port replying 
with the Reject frame. 


Invalid Link_Control 


The command specified in the TYPE field in 
the frame being rejected is invalid or not 
supported as a Link_Control frame. 


Invalid R_CTL field 


The R_CTL field is invalid or inconsistent 
with the other Frame Header fields or con- 
ditions present. 


Invalid F_CTL field 


The F_CTL field is invalid or inconsistent 
with the other Frame_Header fields or con- 
ditions present. 


Invalid OX_ID 


The OX_ID specified is inconsistent with 
the other Frame Header fields or condi- 
tions present. | 


Invalid RX_ID 


The RX_ID specified is inconsistent with the 
other Frame_Header fields or conditions 
present. 


Invalid SEQ_ID 


The SEQ ID specified is inconsistent with 
the other Frame Header fields or condi- 
tions present. 


Invalid DF_CTL 
The DF_CTL field is invalid. 
Invalid SEQ_CNT 


The SEQ CNT specified is inconsistent with 
the other Frame Header fields or condi- 
tions present. A SEQ CNT reject is not 
used to indicate out of order or missing 
Data frames (see F_CTL Abort Sequence). 
An example of use is a Data frame initi- 
ating a Sequence with a SEQ CNT other 
than zero. 


invalid Parameter field 


The Parameter field is incorrectly specified 
or invalid. 


Exchange Error 


An error has been detected in the identi- 
fied Exchange (OX_ID). This could indicate 


Data frame transmission without Sequence 
Initiative or other logical errors in handling 
an Exchange. 


Protocol Error 


This indicates that an error has been 
detected which violates the rules of FC-2 
signaling protocol which are not specified 
by other error codes. 


Unexpected ACK 


An ACK_1 or ACK_N was received from an 
unexpected S_ID. 


Unexpected Link_Response 


A P_BSY was received from an unexpected 
S_ID. 


Data Field too large 


F RJT or P_RdT - the frame being rejected 
exceeded the maximum Receive Data Field 
size specified in the Service Parameters. 


Login Required 


F_RJT or P_RuT - an Exchange is being ini- 
tiated before the interchange of Service 
Parameters (ie. Login) has been per- 
formed. F_RJT may be issued by the 
Fabric in order to notify an N Port that a 
re-Login is required due to changes within 
the Fabric. 


Vendor Unique Error 


The Vendor Unique Error bits shall be used 
by specific Vendors to specify additional 
reason codes. 


Responses: 


R_RDY Primitive (SOFx2, SOFx3) 
Link Response 
— F_BSY 


20.3.3.2 Busy (P_BSY, F_BSY) 


The Busy Link_Response shall indicate that a 
Fabric, if present, or the Responder N Port is 
temporarily occupied with other link activity and 
is not able to receive the frame. A reason code 
is identified in the Parameter field. For Class 1 
Service, Busy shall only be transmitted in 
response to the SOFc1 frame and shall be ended 
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with EOFdt. For Class 2 Service, any Data frame 
may receive a Busy response. A Busy response 
is not used with Class 3 Service. 


A Busy frame (F_BSY, P_BSY) shall not be trans- 
mitted in response to another Busy frame (either 
F_BSY or P_BSY). 


When a Busy frame is received in response to a 
frame transmission, the transmitter of the frame 
shall retransmit the busied frame up to its ability 
to retry. Therefore, a Port shall save sufficient 
information for frames with an SOFc1, or SOF»2 


delimiter for retransmission until an ACK or RJT 


is received. 
F_BSY 


Fabric Busy indicates that the Busy was issued 
by the Fabric. 


P_BSY 


N Port Busy indicates that the Busy was issued 
by the destination N Port. P_BSY is not an 
acceptable response to a Link _Control frame. 
An N Port. shall be required to process 
Link_Control response frames up to its ability to 
transmit unacknowledged Data frames. 


Delimiters: SOFnx, EOFt, EOFat 

Format: FT 0 

Addressing: The D_ID field designates the 
source of the frame encountering the busy con- 
dition while the S_ID field designates the desti- 
nation of the frame encountering the busy 
condition. 

F CTL: The F_CTL field is returned as received 
with the Sequence and Exchange Context bits 
inverted in the F_BSY or P_BSY frame. 

SEQ_ID: The SEQ ID matches the SEQ ID of the 
frame being busied. 

SEQ_ CNT: The SEQ CNT shall be equal to the 
SEQ CNT of the frame encountering the busy 
condition. 

Parameter field The four bytes of this field indi- 
cate the reason for the busy response as defined 
in figure 45. 
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Busy parameter 


First 
Byte 


3 2 
1 4 
AAAA AAAA|CCCC CCCCirrrr rrrriVVVV VVVV 


Action Reason 


Third 
Byte 


Fourth 
Byte 


Second 
Byte 


Figure 45. Busy code format 


Table 34. Busy action codes 


Sequence terminated - retry 
later 


Action 1 


Action 1 indicates that the Recipient has 
busied the Sequence (EOFt or EOFadt). For 
a Class 1 connect-request the busy frame 
is ended with EOFat. The Recipient shall 
only terminate the Sequence on a Busy in 
response to a connect-request (SOFc1) or 
in response to an interlocked Data frame 
associated with X_ID assignment or reas- 
signment (SOFi1, or SOFi2). The frame and 
Sequence are retryable at a later time. 


Applicability: 


— by Fabric when D_ID = Fabric 
— by Fabric when D_ID = N Port 
— by N Port when D_ID = N Port 


Action 2 
Action 2 indicates that the Recipient has 
busied a Class 2 frame and that the 


Sequence has not been terminated. The 
frame is retryable at a later time. 


Applicability: 
— by Fabric when D_ID = Fabric 
— by Fabric when D_ID = N Port 
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Vendor Unique 


— by N Port when D_ID = N Port 


Table 35. Busy reason codes 
Encoded Value Haseolon 
Wd 5, bits 23-16 a 
0000 0001 Fabric busy 


0000 0011 Physical N_ Port busy 
0000 0101 Logical N_ Port busy 


0000 0110 
‘6 Reserved 
1111 1110 
Vendor Unique Busy 
1111 1111 (See Bits 7-0) 


Busy reason codes are defined as follows: 


Fabric busy 


F BSY - the Fabric is blocked from 
delivering a frame to the destination 
N Port specified in the frame being 
rejected. 


Physical N_Port busy 


F BSY - the Fabric is unable to 
deliver the frame being transmitted 


due to a Class 1 Dedicated Con- 
nection active at the destination 
N_ Port. | 


P_BSY - the destination N_Port link 
facilities are currently busy and the 
N_ Port is unable to process the frame 
received. 


Logical N_Port Busy 


P BSY - the destination N Port is 
unable to complete the Data frame 
request at the present time due to the 
logical state of the N Port facilities. 
Logical N Port Busy may also be indi- 
cated by an_ Application Reject 
(A_RJT) Link_Data reply frame (see 
21.5.2). 


Vendor Unique Error 


The Vendor Unique Error bits shall be 
used by specific Vendors to specify 
additional reason codes. 


Responses: 


R_RDY Primitive (SOFx2, SOFx3) 
Link_Response 
— F_RJT, P_RJT — 


20.4 Data Protocol Summary 


Table 36 summarizes the Data transfer by Data 
frames and Sequences for Class 1,2, and 3. The 
“PROTOCOL” columns represent an example 
Request-Reply protocol with frames __ inter- 
changed by two N Ports in order to accomplish 
an Upper Level Protocol request and its associ- 
ated reply. Other Protocols are also possible 
within the definition of FC-2. 
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The "FRAME RESPONSE” columns. represent 
possible Link Control frame responses for suc- 
cessful ("expected”), or unsuccessful (alter- 
nate”) delivery to the N_ Port plus R_RDY. 


An FC-4 Data protocol may be defined by speci- 
fying the request Data Sequence and the reply 
Data Sequence such as the Link Application pro- 
tocol. Other protocol models may be derived 
using Data frame Sequences. The _ protocol 
shown represents an example of how a protocol 
relates to frame flow. 


Table 36. Data Protocol Summary 


PROTOCOL 


Request Reply 


fewest] SC~* 


reply frame Sequence 
or No reply Sequence 


reply frame Sequence 
or No reply Sequence 


Data frame Data 
reply frame Sequence 
or No reply Sequence 


FRAME RESPONSE (LINK_CONTROL) 
Expected Alternate 


Expected Alternate 
ACK Link_Response 


F _BSY / PBSY or 
F RUT/ P_RUT 


R_RDY Primitive to 
SOFc1, 
ACK_1 or ACK_N 


R_RDY primitive plus 
ACK_1 or ACK_N 


R_RDY primitive plus 
F_BSY / P_BSY or 
F_RJT/ P_RJT 


R_RDY primitive 
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21 Link Applications 


21.1 Introduction 


Link_Data application frames represent a man- 


datory FC-4 for each N Port. These protocols 
shall operate according to R_RDY Primitive, 
ACK, and Link_Response rules specified in 
clause 20. 


A Sequence of Link _Data frames is logically 
viewed as a request or a reply to a previous 
request. A request Sequence solicits a destina- 
tion N_Port to perform a function or service. The 
request may include command, control, data, or 
status information. A reply Sequence may be 
transmitted in answer to a request Sequence 
and may contain command, control, data, or 
status information. 


Link_Data Sequences provide “Link Application” 
or N_Port level functions required to support an 
N_ Port. Combinations of Request and Reply 
Sequences constitute a Link Application Upper 
Level Protocol. | 


21.2 Routing control 


Since Link Application requests and replies may 
deal with low-level FC-2 functions, an N_ Port or 
F Port may use the Link Data identification in 
the DL bits in R_CTL in order to route the frame. 
All Link application frames set TYPE = Link 
Application. 


21.3 Link_Application command 
codes 


When TYPE indicates Link Application, the first 
word of the Payload (LA_Command code) of the 
Request or Reply Sequence shall be encoded as 
shown in table 37 with bits 23-0 reserved. 
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Table 37. LA_Command codes 


Encoded 
Value 
(Bits Description 
31-24) 


0000 0000 No Operation 


0000 001 | LInk_Application LA_RJT 
Reject 


A 


0000 0110 Abort Sequence ABTS 
0000 0111 
nection 
0000 1000 Read Connection 
Status 
Read Exchange 
0000 1001 Sarid 
Read Sequence 
seid Status Block 
0000 1011 Establish 


Streaming 


0000 1100 Estimate Credit 
0000 1101 Advise Credit 


21.4 Link_Data Requests 


R 
R 


BTX 
McC 
CS 
RES 
RSS 


ESTS 


ESTC 
ADVC 


A Sequence Initiator transmits a Link Data 
Sequence in order to solicit the destination 
N Port to perform a Link-Level function or 
service. A Link Data Protocol is composed of a 
Link Data request Sequence and a Link_Data 
reply Sequence. The last Data frame of a 
Link Data request Sequence transfers’ the 
Sequence Initiative to the Recipient in order to 
allow the reply to be transmitted. (See clause 


24.) The following Link_Data Protocols are 
defined: 

— Login 

— Logout 


— Abort Exchange 

— Abort Sequence 

— Read Connection Status 

— Read Exchange Status Block 
— Read Sequence Status Block 
— Establish Streaming 


ee ees 


— Advise Credit 


The following Link Data requests have no reply 
Sequence: 


— No Operation 
— Remove Connection 
— Estimate Credit 


This section specifies Link Data request 
Sequences. In the Link commands described in 
the following sections, emphasis is placed on the 
function performed by the Link Data Request 
and its associated Link_Data Reply Sequences. 
Frame_Header fields used in normal Exchange 


and Sequence management are not discussed in 


detail. See clause 24 for more information 
regarding use of F_CTL Bits for Exchange and 
sequence control as well as OX_ID, RX_ID, 
SEQ ID, and Sequence Count. 


Payload 

Link_Data requests and Link _Data reply frames 
use an FT_1 frame type. The Payload contains a 
multiple of four bytes of data based on the indi- 
vidual Link_Data Request or Reply. If required, 
more than one frame may be used to form a 
request or reply Sequence. 


21.4.1 Login (LOGI) 


The Login Link_Data frame shall transfer Service 
Parameters from the initiating N Port to the 
N_ Port associated with the Destination Identifier 
using single InBand addressing. The LOGI 
frame provides the means by which an N_Port 
may request “Login” with a Fabric or another 
N_ Port prior to other Data frame transfers (see 
23.1). 


The interchange of Service Parameters, which 
includes World Wide Names, establishes the 
operating environment between the two N Ports. 
Three Classes of Service are _ available 
depending on the support provided by the 
Fabric, if present. (See 23.5 for a definition of 
service Parameters). 


In order to Login with the Fabric and determine 
the Fabric operating characteristics, an N_ Port 
specifies the Destination Identifier as the well- 
known Fabric F_Port Identifier (i.e. hexadecimal 
‘FFFFFE’). 


In order to direct the Login Link _Data frame to 
the Fabric Server, an N_Port specifies the appro- 
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priate well-known Address Identifier (see table 
26 in 18.3). 
Protocol: 


Login request Sequence 
Accept reply Sequence 


Delimiters: SOFc1, SOFix, EOFn. 

Format: FT_1 

Addressing: The S_ID field designates the 
source N_ Port requesting Login. If unknown, as 
in Fabric Login, binary zeros are used. The D_ID 
field designates the destination N Port of the 
Login. 

Payload: The Payload shall be 68 bytes in size. 
The first word shall contain the LA_Command 
code. The next 48 bytes shall contain the 
Service Parameters for all Classes of Service. 
The next eight bytes. shall contain’ the 
World_wide_ Name of the Originator N_ Port initi- 
ating the LOGI Data frame. Service Parameters 
are defined in 23.5. The remaining bytes of this 
field are reserved. 

Reply Link_Data Sequence: 


— Application Reject (LA_RuT) 
signifies rejection of the LOGI command 
(See 21.5.2) 

— Accept (ACC) 
signifies successful 
LOGI command 

— Accept Payload 
contains the LA_Command code followed 
by the Service Parameters and 
World_wide Name of the Responder 
N Port or the Fabric in the same format 
as the LOGI Data frame. (See 23.5) 


completion of the 


21.4.2 Logout (LOGO) 


The Logout Link Data frame shall request invali- 
dation of the Service Parameters and 
World wide Name which have been saved by an 
N_ Port, freeing those resources. This provides a 
means by which an N_ Port may request “Logout” 
or remove Service between two N_Ports. (See 
23.4) 

Protocol: 


Logout request Sequence 
Accept reply Sequence 


Delimiters: SOFc1, SOFix, EOFn. 

Format: FT 1 

Addressing: The S_ID field designates the 
source N_ Port requesting Logout. The D_ID field 
designates the destination N Port of the Logout 
request. 
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Payload: The Payload shall contain the 
LA Command code. 


Reply Link_Data Sequence: 


— Application Reject (LA_RJT) 
| signifies rejection of the LOGO command 
(See 21.5.2) 
— Accept (ACC) 
signifies that Service has been removed. 
— Accept Payload: 
contains the LA_Command code. 


21.4.3 Abort Exchange (ABTX) 


The Abort Exchange Link Data frame shall be 
used to request abnormal termination of an 
Exchange in progress. The Payload shall 
contain the OX_ID and assigned RX_ID for the 
Exchange being aborted, as well as the S_ID of 
the N Port which initiated the Exchange. 
Resources associated with the OX_ID in the 
Originator, and with the RX_ID in the Responder, 
shall be released. Either the Originator or 
Responder are permitted to Abort an Exchange. 


Transmission of an ABTX frame is allowed while 
the identified Exchange is_ active. The 
Responder shall insure that the RX_ID being ter- 
minated is currently associated with the OX_ID 
specified in the ABTX request. If the Sequence 
Initiator has indicated that X_ID reassignment is 
required during Login, the Sequence Initiator 
shall include the Association Header in the 
ABTX frame. | 


Both the OX_ID and RX_ID are available by the 
respective N_Ports for reuse after the Exchange 
has been successfully aborted. Any active 
Sequences associated with the Exchange are 
also abnormally terminated by each N Port The 
ACC reply confirms that all Sequences and the 
Exchange have been abnormally terminated. 
The Abort Sequence Protocol is not explicitly 
required. 


The addressing is fully specified by the D_ID and 
S_ID fields using InBand addressing. 
Protocol: 


Abort Exchange request Sequence 
Accept reply Sequence 


Delimiters: SOFnx, EOFn. 
Format: FT_ 1 
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Addressing: The D_ID field designates the desti- 
nation N Port of the Exchange being aborted 
while the S_ID field designates the source 
N_ Port which is requesting that the Exchange be 
aborted. 

X_ID: A separate and distinct Exchange is 
required other than the Exchange being aborted 
in order to properly track status. 

SEQ_ID, SEQ_CNT: The SEQ_ID and the 
SEQ CNT shall be appropriate for an active 
Sequence. 

Payload: The first word shall contain the 
LA Command code. The first byte of the second 
word shall be reserved. The second, third, and 
fourth bytes of the second word shall contain the 
SID of the N Port which originated the 
Exchange. The third word contains. the 
Exchange IDs. The first two bytes of the third 
word shall contain the OX_ID and the third and 
fourth bytes of the second word shall contain the 
RX_ID for the Exchange being aborted. If the 
Sequence Recipient has indicated that X_ID 
reassignment is required during Login, the 
Sequence Initiator shall include the Association 
Header in the Payload of the ABTX request asso- 
ciated with the Exchange being aborted imme- 
diately following the first three words. 

Reply Link_Data Sequence: 


— Application Reject (LA_RJT) 
signifies rejection of the ABTX command 
(See 21.5.2) 

— Accept (ACC) 
signifies that the destination N_ Port has 
terminated the Exchange. 

— Accept Payload 
shall contain the LA_Command code. 


21.4.4 Abort Sequence (ABTS) 


The Abort Sequence Link Data frame shall be 
used to request abnormal termination of the 
Sequence in progress which is identified by the 
SEQ ID of this frame. The RX_ID and OX_ID 
specified shall be associated with the Sequence 
(SEQ ID) being terminated. Resources associ- 
ated with the SEQ ID shall be released. 


Transmission of the ABTS frame shall only be 
allowed before the identified Sequence (SEQ _ ID) 
is terminated. The Sequence Initiator shall 
transfer the Sequence Initiative to the Recipient 
by the appropriate F_CTL bit setting. 


The Sequence Recipient may request that an 
active Sequence in progress be aborted by 
setting the Abort Sequence Condition bits to 
values of 0 1 or 10 on an ACK frame. 


After receiving the ABTS frame, the Recipient 
shall insure that the SEQ ID being terminated is 
currently associated with the SEQ ID specified in 
the ABTS request. The Recipient of the ABTS 
frame shall withhold transmission of the Accept 
frame until all frames of the Sequence have 
been accounted for or timed out. Data frames 
for the Sequence may be processed, or dis- 
carded based on the policy of the FC-4 receiving 
the Data. One Sequence may be aborted by the 
Recipient. See 29.7.1. 


The SEQ ID shall be retired by the Sequence Ini- 
tiator until the Accept reply Sequence is 
received. For purposes of further Data trans- 
mission the Exchange using this Sequence is 
suspended. The SEQ_ID shall be available for 
reuse by the Recipient after transmission of the 
Accept. The Recipient shall update the status of 
the Sequence in the Exchange Status Block. 


The addressing is fully specified by the D_ID and 
S_ID fields using InBand addressing. 
Protocol: 


Abort Sequence request Sequence 
Accept reply Sequence 


Delimiters: SOFnx, EOFn. 

Format: FT_1 

Addressing: The D_ID field designates the desti- 
nation N Port (Sequence Recipient) of the 
sequence being aborted while the S_ID field 
designates the source N Port (Sequence Initi- 
ator) which is requesting that the Sequence be 
aborted. 

X_ID: Both the RX_ID and OX_ID shall corre- 
spond to the Sequence being aborted. 

SEQ_ID, SEQ CNT: The SEQ ID shall be appro- 
priate for the active Sequence. The SEQ CNT 
shall be set to its normal value for the Sequence 
in progress, indicating the highest SEQ CNT 
transmitted for this SEQ_ID. 
Payload: The Payload 
LA_Command code. 


shall contain. the 
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Reply Link_Data Sequence: 


— Application Reject (LA_RuJT) 
signifies rejection of the ABTS command 
(See 21.5.2) 

— Accept (ACC) 
signifies that the destination N_Port has 
terminated the Sequence. 

— Accept Payload 
The first word is the LA_Command code. 
Following the command code, the 
aborted Sequence is identified by two 
words of data. The first byte of the two 
words shall specify the SEQ ID being 
aborted. The second, third, and fourth 
bytes of the two words shall contain the 
S_ID of the N_Port which originated the 
Exchange. The fifth and sixth bytes of 
the two words shall contain the OX_ID 
and the seventh and eighth bytes of the 
two words shall contain the RX_ID for the 
Sequence being aborted. 


21.4.5 No Operation (NOP) 


The No Operation Link Data frame shall be used 
with any SOF and EOF delimiters appropriate to 
the Class in which it is being used. The NOP 
frame is discarded by the recipient. However, 
the F_CTL field and the SOF and EOF delimiters 
are examined and the appropriate action taken 
by both the N_ Port and Fabric, if present. 
Protocol: 


No Operation request 


Delimiters: SOFc1, SOFix, SOFnx, EOFn, EOFt, 
EOF dt. 

Format: FT 1 

Addressing: The D_ID field designates the desti- 
nation of the frame while the S_ID field desig- 
nates the source of the frame. 

Payload: The first word of the Payload shall 
contain the LA Command code. The remaining 
Payload size and content shall be unspecified 
and may contain any appropriate number of 
words. 

Reply Link_Data Sequence: 


— none or another NOP 
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21.4.6 Remove Connection (RMC) 


The Remove Connection Link _Data frame shall 
be used with the EOFdt to remove a Class 1 Ded- 
icated Connection. The RMC frame shall be dis- 
carded by the Recipient, however, the F_CTL 
field and the EOFdt shall be examined and proc- 
essed appropriately by both the N Port and 
Fabric, if present. 

Protocol: 


Remove Connection request 


Delimiters: SOFc1, SOFi1, SOFn1, EOFat 

Format: FT_ ‘1 

Addressing: The D_ID field designates the 
Recipient of the Sequence while the S_ID field 
designates the Initiator of the Sequence. 
Payload: The Payload contains’ the 
LA_Command code. 

Reply Link_Data Sequence: 


— none 


21.4.7 Read Connection Status (RCS) 


The RCS Link_Data frame requests the Fabric 
Controller to return the current Dedicated Con- 
nection status for the N Port specified in four 
bytes of the Payload of the RCS frame. The RCS 
_ request provides the means by which an N_Port 
may interrogate the Fabric for its current Con- 
nection status or the Connection status of other 
N_ Ports within the Fabric. 


In order to direct the RCS Link _Data request 
_ frame to the Fabric, an N_ Port specifies the Des- 
tination Identifier as a well-known Fabric F_Port 
address (i.e. hexadecimal ’FFFFFE’). 

Protocol: 


Read Connection Status request Sequence 
Accept (ACC) reply Sequence 


Delimiters: SOFc1, SOFix, EOFn. 

Format: FT_1 

Addressing: The S_ID field designates the 
source N Port requesting Connection status. 
The D_ID field is the Fabric F_Port, hexadecimal 
‘FFFFFE’. 
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Payload: The first word of the Payload shall 
contain the LA Command code. The second 
word shall contain the N_Port address identifier 
for which Connection status is being requested. 
The format of the second word of the Payload is 
specified in figure 46. 


RCS Payload Definition — Second Word 


First Second Third Fourth 
Byte Byte Byte Byte 


3 212 Wild 
1 413 876|5 817 
reer rer] AARA AAAA|AAAA AAAA|AAAA AAAA 


Reserved Address Identifier 


Bits 


Figure 46. Connection address identifier 


Bits 31 - 24 Reserved 
Bits 23 - 0 


Bits 23 through O specify the address iden- 
tifier of the N Port whose Connection 
status is being requested. If the address is 
the same as the address of the source 
N Port, then the status returned indicates 
whether the N Port transmitting the RCS 
Link_Data request frame is currently Con- 
nected and to which N_ Port. 


Reply Link_Data Sequence: 


— Application Reject (LA_RJT) 
signifies rejection of the RCS command 
(See 21.5.2) 

— Accept (ACC) 
signifies that the Fabric has completed 
the request. 

— ACC Payload 
The first word of the Payload shall 
contain the LA Command code. The 
second word shall contain the Con- 
nection status and the address identifier 
to which the requested N Port is Con- 
nected, if that N_ Port is in a Dedicated 
Connection. The format of the Payload is 
specified in figure 47. 


ACC Payload Definition — second word 


First Second Third Fourth 
Byte Byte Byte Byte 


3 2\2 111} 1 
] 413 876}5 8} 7 0 
SSSS_ rrrr}AAAA AAAA|AAAA AAAA}AAAA AAAA 


Status Address Identifier 


Bits 


Figure 47. Connection status information 


Connection Status Codes: 
Bit 31 - Connect-request delivered 


If bit 31 is zero, the specified N Port is 
either not Connected, or is involved in an 
Established Connection based on _ the 
setting of bit 29. If bit 31 is one, a connect- 
request has been delivered to the specified 
N Port, but the N Port has not yet 
responded with a proper response frame 
and a Dedicated Connection does not yet 
exist. 


Bit 30 - Connect-request queued 


If bit 30 is zero, no connect-request is 
queued for the specified N_ Port. If bit 30 is 
one, a connect-request is queued, but has 
not been delivered to the specified N_ Port. 


Bit 29 - Connection Established 


If bit 29 is zero, the specified N_Port in the 
RCS request is not in a Dedicated Con- 
nection. If bit 29 is one, the specified 
N_ Port is involved in a Dedicated Con- 
nection. When bit 29 is one, the address 
identifier in bits 23-0 identifies the N Port 
involved in the Dedicated Connection. 


Bit 28 - Intermix 


If bit 28 is zero, the N Port specified in the 
RCS frame is not supporting intermix. If bit 
28 is one, the N Port specified in the 
request is actively supporting intermix for 
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Class 2 or Class 3 when a Dedicated Con- 
nection exists. See 23.5. for more dis- 
cussion of intermix. 


Bits 23 - 0 


Bits 23 through O specify the address iden- 
tifier of the N Port involved in a Dedicated 
Connection with the N_ Port specified by the 
RCS Link Data request Sequence frame. 


21.4.8 Read Exchange Status Block 
(RES) 


The RES Link_Data frame requests an N Port to 
return the Exchange Status Block for the RX_ID 
or OX_ID originated by the S_ID specified in the 
Payload of this frame. This provides the N_ Port 
transmitting the request with — information 
regarding the current status of the Exchange 
specified. 

Protocol: 


Read Connection Status request Sequence 
Accept (ACC) reply Sequence. 


Delimiters: SOFc1, SOFix, EOFn. 

Format: FT_1 

Addressing: The S_ID field designates the 
source N_ Port requesting the Exchange Status 
Block. The D_ID field designates the destination 
N_ Port to which the request is being made. 
Payload: The first word of the Payload shall 
contain the LA_Command code. The first byte of 
the second word of the Payload shall be 
reserved. The second, third, and fourth bytes of 
the second word shall contain the S_ID of the 
N_ Port which originated the Exchange. The first 
and second bytes of the third word of the 
Payload shall contain the OX_ID. The third and 
fourth bytes of the third word shall contain the 
RX_ID. The OX_ID and RX_ID Specified are 
associated with the Exchange Status Block being 
requested. If the Sequence Recipient has indi- 
cated that X_ID reassignment is required during 
Login, the Sequence Initiator shall include the 
Association Header in the Payload of the RES 
request immediately following the first twelve 
bytes. 
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RES Payload Definition — after LA Command 


First Second Third Fourth 
Byte Byte Byte Byte 


3 212 111}1 | 
1 43 876{5 87 0 
Originating S_ID 

OX_ID RX_ID 


Figure 48. RES Payload 


Bits 


2nd Wd 


3rd Wd 


Reply Link_Data Sequence: 


— Application Reject (LA_RuT) 
signifies rejection of the RES command 
(See 21.5.2) 

— Accept 
signifies that the N_ Port has transmitted 
the requested data. | 

— Accept Payload: 
The first word of the Payload shall 
contain the LA_Command code. _ The 
remainder of the Payload shall contain 
the information representing the 
Exchange Status Block for the RX_ID or 
OX_ID specified in the RES request 
sequence. The format of the Exchange 
Status Block is specified in 29.11.3. 


21.4.9 Read Sequence Status Block 
(RSS) 


The RSS Link_Data frame requests an N_ Port to 
return the Sequence Status Block for the SEQ ID 
specified in the Payload of this frame. The 
Payload also specifies the S_ID of the Sequence 
Initiator as well as the associated OX_ID and 
RX_ID. This provides the N_Port transmitting the 
request with information regarding the current 
status of the Sequence it identified. 

Protocol: 


Read Sequence Status request Sequence 
Accept (ACC) reply Sequence 


Delimiters: SOFc1, SOFix, EOFn. 

Format: FT_ 1 

Addressing: The S_ID field designates the 
source N Port requesting the Sequence Status 
Block. The D_ID field designates the destination 
N_ Port to which the request is being made. 
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Payload: The first word of the Payload shall 
contain the LA Command code. The first byte of 
the second word of the Payload shall contain the 


SEQ ID of the Status Block being requested. 


The second, third, and fourth bytes of the second 
word contain the S_ID of the N_ Port which initi- 
ated the Sequence. The first and second bytes 
of the third word of the Payload shall contain the 
OX_ID. The third and fourth bytes of the third 
word shall contain the RX_ID. The OX_ID and 
RX_ID specified are associated with the 
Sequence Status Block being requested. 


RSS Payload Definition — after LA Command 


First Second Third Fourth 
Byte Byte Byte Byte 


3 212 
1 4}3 
SEQ_ID Originating S_ 
OX_ID RX_ID 


Figure 49. RES Payload 


Bits 111} 1 


876|5 8|7 0 
ID 


ond Wd 


3rd Wd 


Reply Link_Data Sequence: 


— Application Reject (LA_RudT) 
signifies rejection of the RSS command 
(See 21.5.2) 
— Accept 
signifies that the N_ Port has transmitted 
the requested data. 
— Accept Payload: 7 
The first word of the Payload shall 
contain the LA Command code. The 
remainder of the Payload shall 
contain the information representing 
the Exchange Status Block for the 
RX_ID or OX_ID specified in the RSS 
request Sequence. The format of the 
Sequence Status Block is specified in 
29.11.4. 


21.4.10 Establish Streaming (ESTS) 


The ESTS Link Data requests a temporary allo- 
cation of Credit known as Streaming Credit large 
enough to perform continuous streaming of Data 
frames. (See 23.7.1.1 for the usage of this 
frame). 


Protocol: 


Establish Streaming request Sequence 
Accept reply Sequence 


Delimiters: SOFc1, SOFix, EOFn. 

Format: FT 0 

Addressing: The S_ID field designates the 
source N_ Port requesting Streaming. The D_ID 
field designates the destination N Port 
addressed. 

Payload: The Payload shall contain’ the 
LA Command code. 

Reply Link_Data Sequence: 


— Application Reject (LA_RJT) 
signifies rejection of the RSS command 
(See 21.5.2) 

— Accept (ACC) 
signifies successful completion of the 
ESTS function. 

— Accept Payload 
shall contain Payload in the same format 
as the ACC response to LOGI Link_Data 
frame for Service Parameters. The 
Payload shall contain Streaming Credit 
(L) allocated in Credit field of the appro- 
priate Class of the Service Parameters. 
The other Service Parameter fields shall 
be ignored by the receiver. 


21.4.11 Estimate Credit (ESTC) 


The ESTC Link Data request shall be used to 
estimate the minimum Credit required to achieve 
the maximum bandwidth for a given distance 
between an N Port pair. The ESTC Link Data 
request shall have the maximum frame size as 
determined by Login with the destination N_ Port. 


The ESTC Link Data frame shall be transmitted 
as a streamed Sequence. The destination 
N_ Port shall respond with an ACK_1 for each 
ESTS Link_Data frame received. (See 23.7.1.2 
for the usage of this frame.) 


Protocol: 


Estimate Credit request Sequence 
No reply Sequence 


Delimiters: SOFix, EOFn. 

Format: FT 1 

Addressing: The S_ID field designates the 
source N_Port requesting the Credit estimate. 
The D_ID field designates the destination N_ Port 
specified in the Establish Streaming frame. 
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Data Field: The first word of the Data Field shall 
contain the LA Command code. The remainder 
of the Data Field size shall be the maximum as 
determined by Login. The content of the Data 
Field after LA Command shall be valid data 
characters. 

Reply Link_Data Sequence: 


— None. 


21.4.12 Advise Credit (ADVC) 


The ADVC Link Data request shall be used to 
advise the destination N Port of the estimated 
Credit which the source N_ Port requests to be 
allocated. (See 23.7.1.3 for the usage of this 
frame) The ADVC request may also be used 
independently from the Estimate Credit proce- 
dure. 


Protocol: 


Revise Credit request Sequence 
Accept reply Sequence 


Delimiters: SOFix, EOFn. 

Format: FT_ 1 

Addressing: The S_ID field designates the 
source N Port requesting Credit revision. The 
D_ID field designates the destination N_ Port. 
Payload: The first word of the Payload shall 
contain the LA_Command code. The data which 
follows is in the same format LOGI Link_Data 
frame for Service Parameters. The Payload 
shall contain estimated Credit (M+1) in Credit 
field of the appropriate Class of the Service 
Parameters. The other Service Parameter fields 
shall be ignored by the receiver. 

Reply Link_Data Sequence: 


— Application Reject (LA_RJT) 
signifies rejection of the ADVC command 
(See 21.5.2) 

— Accept (ACC) 
signifies successful completion of the 
ADVC function and modifies the actual 
Credit value. 

— Accept Payload 
shall contain data in the same format as 
the ACC response to a LOGI Link_Data 
frame for Service Parameters. The 
Payload shall contain revised Credit allo- 
cated in Credit field of the appropriate 
Class of the Service Parameters. The 
other Service Parameter fields shall be 
ignored by the receiver. This revised 
Credit value is determined by the desti- 
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nation N Port based on its buffering 
scheme, buffer management, buffer 
availability, and N_Port processing time. 
(see 23.7.1.3 for the determination of this 
value) | 


21.5 Link_Data Reply Sequences 


A Link_Data reply Sequence signifies that the 
Link_Data request Sequence is completed. The 
reply Sequence may contain data in the Payload 
following the LA_Command code word. The 
format and meaning of the Payload is specified 
in the request Link_Data definition. Link Data 
frames set DL Bits 31-30 in R_CTL to 1 0. 


21.5.1 Accept (ACC) 


The Accept Link_Data reply Sequence notifies 
the transmitter of a Link_Data request that a pre- 
vious Link_Data Sequence has been completed. 
The first word of the Payload contains the 
LA Command code. The remainder of the 
Payload is unique to the request Link Data 
Sequence being replied to. 


Protocol 


Accept is the reply Sequence to Login, Logout, 
Abort Exchange, Abort Sequence, Read Con- 
nection Status, Read Exchange Status Block, and 
Read Sequence’ Status. Block, Establish 
Streaming, and Advise Credit request 
Sequences. 


Delimiters: SOFnx, EOFt, EOFat 

Format: FT_1 

Addressing: The D_ID field designates the 
source of the Link Data frame being accepted 
while the S_ID field designates the destination of 


the request Data frame Sequence _ being 
accepted. 
Payload: The Payload content following the 


LA_Command code is defined within individual 
Link_Data requests. 
Reply Link_Data Sequence: 


— none 
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21.5.2 Link Application Reject (LA_RJT) 


The Link Application Reject (LA_RUJT) notifies the 
transmitter of a Link Data request that a pre- 
vious Link Data Sequence has been rejected. A 
four-byte reason code is contained in the 
Data Field. Application Rejects may be trans- 
mitted for a variety of conditions which may be 
unique to a specific Link_Data request. 


For example, if the Service Parameters specified 
in a Login frame were logically inconsistent or in 
error, a P_RJT frame would not be transmitted in 
response, but rather an Application Reject from 
the Upper Level. 


Protocol 


LA_RJT may be a reply Sequence to any Link 
Application request. 


Delimiters: SOFnx, EOFt, EOFat 

Format: FT_1 

Addressing: The D_ID field designates the 
source of the Link Data request being rejected 
while the S_ID field designates the destination of 


the request Data frame Sequence being 
rejected. 
Payload: The first word of the Payload shall 


contain the LA_Command code. The next four 
bytes of this field indicate the reason for 
rejecting the request. (See figure 50 and tables 
38 and 39.) 


Application Reject data definition — second word 


First Second Third Fourth 
Byte Byte Byte Byte 


3 2 
1 4 
A 


7 0 
AAA AAAA|CCCC CCCC}EEEE EEEE|VVVV VVVV 


Action Reason 
Codes Code 


Figure 50. LA_RJT format 


Bits 


Reason Vendor 
Explanation Unique 


Table 38. Action Codes 


Encoded Value 


bits 31-24 Description 


Abort Sequence requested - 


0000 0001 (1) retry after correction 


Abort Sequence requested - 


0000 0010 (2) non-retryable error 


Other codes Reserved 


Action 1 


Action 1 indicates that the Recipient is 
requesting the source of the rejected frame 
to abort the Sequence. The Sequence is 
retryable if the corrective action indicated 
by the reason code is performed: 


— Logical error 
— Logical busy 
— Protocol error 
— Vendor unique error 


Action 2 


Action 2 indicates that the Recipient is 
requesting the source of the rejected frame 
to abort the Sequence or Exchange. The 
Sequence is non-retryable for the following 
reason codes: 


— Invalid LA_Command code 
— Vendor unique error 


Table 39. Link Application reason codes 


Encoded Value 


(Bits 23-16) Description 


0000 0001 pea code 
0000 0011 
0000 0101 
0000 0111 


Others 


Logical error 


Logical busy 


-Protocol error 
Reserved 


Vendor Unique Error 


11444911 (See Bits 7-0) 


Reject reason codes are arranged in descending 
priority as the encoded value increases. There- 
fore, if invalid LA_Command code is the reject 
reason code, no additonal checking of the frame 
is required and no other errors are reported. 
The first error encountered according to the pri- 
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ority specified is the error reported and further 
error checking is not required. 


Bits 15-8 specify an additional reason explana- 
tion which may be unique for a specific request. 


¢ Bits 23-16 Description 


Invalid LA_Command code 


The LA_Command code in the Sequence 
being rejected is invalid or not supported 
for the Link Application TYPE. 


Logical error 


The request identified by the LA Command 
code and Payload content is_ logically 
inconsistent for the conditions present. 


Logical busy 


The FC-4 identified by the Type field is log- 
ically busy and unable to process the 
request at this time. 


Protocol Error 


This indicates that an error has been 
detected which violates the rules of FC-4 
protocol which are not specified by other 
error codes. 


Vendor Unique Error 


The Vendor Unique Error bits shall be used 
by specific Vendors to specify additional 
reason codes. 


¢ Bits 15-8 Reason explanation 


The reason explanation table shown (table 40) is 
based on an LA_RJT to a Login request. The 
explanations listed help identify the specific field 
in the Service Parameters which is in error. 


Table 40 (Page 1 of 2). Application Reject 
Explanation 


Encoded Value 
(Bits 15-8) 


0000 0001 


Service Parm error 
- Options 


0000 0011 


Service Parm error 
- Transmitter Ctl 
Service Parm error 
- Receiver Ctl 
Service Parm error 
- Rec Data field size 


0000 0101 


0000 0111 
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| Table 40 (Page 2 of 2). Application Reject 
| Explanation. 
Encoded Value _ |. Hescrosn 
(Bits 15-8) P 
- Concurrent Seq 
Service Parm error 
0000 1111 
Reserved 


to 
Reply Link_Data Sequence: 


1111 1110 


— none 
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21.5.3 No Operation (NOP) 


The No Operation Link Data frame shall be used 
with any SOF and EOF delimiters appropriate to 
the Class in which it is being used. The NOP 
frame shall be discarded by the Recipient, 
however, the F_CTL field and the SOF and EOF 
delimiters are examined and the appropriate 
action taken by both the N Port and Fabric, if 
present. 
Delimiters: 
EOFdt. 
Format: FT_1 
Addressing: The D_ID field designates the desti- 
nation of the frame while the S_ID field desig- 
nates the source of the frame. 

Payload: The first word of the Payload shall 
contain the LA_Command code. The remaining 
Payload size and content shall be unspecified 
and may contain any appropriate number of 
words. 

Reply Link_Data Sequence: 


SOFc1, SOFix, SOFnx, EOFn, EOFt, 


— none, or 
— NOP 
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21.6 Link Application Summary 
Table 41 summarizes the Link Application 


request and reply Sequences. The Payload 
content and size in bytes are specified. 


Table 41. Link Application Payload 


REQUEST SEQUENCE REPLY SEQUENCE 
Request Payload Reply Payload 
Login LA Command code, Accept (ACC) LA Command code, 
(LOGI) Service Parameters or A_RJT Service Parameters 
| (Class 1, 2, 3) (Class 1, 2, 3) 
World_Wide_Name, World_Wide_Name, 
(68 bytes) (68 bytes) 


Logout LA_Command code 
(LOGO) (4 bytes) 
Abort Exchange LA Command code, 
(ABTX) S_ID, 


OX_ID, RX_ID 
(12 bytes) 


Abort Sequence LA Command code 
(ABTS) (4 bytes) 
No Operation LA_Command code 
(NOP) (4 bytes) 


Accept (ACC) LA_Command code 
or A_RJT (4 bytes) 


Accept (ACC) 
or A_RJT 


LA_Command code 
(4 bytes) 


Accept (ACC) LA_Command code 
or A_RUT (4 bytes) 
No Operation, or LA Command code 
None (4 bytes) 


Remove Connection LA_Command code LA_Command code 
(RMC) (4 bytes) (4 bytes) 


Read Connection LA_Command code, 
Status (RCS) Address_Identifier 
(8 bytes) 


Accept (ACC) 
or A_RJT 


LA_Command code, 
Status, 
Address_ldentifier 
(8 bytes) 


Read Exchange LA Command code, 
Status Block (RES) Originating S_ID, 
OX_ID , RX_ID 
(12 bytes) 


LA_Command code, 
SEQ_ID, S_ID, 
RX_ID, OX_ID 
(12 bytes) 


LA Command code 
(4 bytes) 


Accept (ACC) 
or A_RJT 


LA Command code, 
Exchange SB Format 
( N bytes ) 


Read Sequence 
Status Block (RSS) 


Accept (ACC) 
or A_RJT 


LA_Command code, 
Sequence SB format 
( N bytes ) 


Establish Streaming 
(ESTS) 


Accept (ACC) 
or A_RJT 


LA_Command code, 
Service Parameters 
( 52 bytes ) 


Estimate Credit | 
(ESTC) 


LA_Command code, 
Data 
(maximum size) 


LA_Command code 
(4 bytes) 


Advise Credit 
(ADVC) 


LA_Command code, 
Service Parameters 
( 52 bytes ) 


Accept (ACC) 
or A_RJT 


LA_Command code, 
Service Parameters 
( 52 bytes ) 
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22 Classes of service 


Three Classes of service applicable to a Fabric 
and an N_Port are specified in FC-2. These 
Classes of service are distinguished primarily by 
the methodology with which the communication 
circuit is allocated and retained between the 
communicating N_Ports and the level of delivery 
integrity required for an application. A given 
Fabric or N Port may support one or more 
Classes of service. These Classes of service 
are: 


1. Class 1 - Dedicated Connection 
2. Class 2 - Multiplex 
3. Class 3 - Datagram 


Each Class of service may be supported with 
any of the Communication Models. 


22.1 Class 1 -- Dedicated Connection 


Class 1 is a service which provides Dedicated 
Connections. A Class 1 Connection is requested 
by an N_Port with another N Port. Once a Con- 
nection is established, it is retained and guaran- 
teed by the Fabric. 


22.1.1 Class 1 function 


A Class 1 service is requested by an N Port with 
another N_ Port via transmission of a frame con- 
taining a SOFc1. The Fabric, if present, allocates 
a circuit between the requesting N Port and the 
destination N Port. The destination N Port 
transmits a frame indicating its acceptance to 
the requesting N_ Port. The Fabric retains the 
allocated circuit between these two N Ports, 
until one of these N Ports requests the service 
to be removed. 


Even if a Fabric is not present, the requesting . 


N Port and the destination N_ Port follow the 
same protocol. 


Class 1 Delimiters as specified in 22.1.3 are used 
to establish and remove the service and to ini- 
tiate and terminate one or more Sequences 
within the service. 
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22.1.2 Class 1 rules 


The rules specified in this section apply to 
“exclusive” Class 1 Connections. (See 22.4 for 
additional rules which apply to Intermix). To 
provide a Class 1 Connection, the transmitting 
and receiving N_Ports, and the Fabric shall obey 
the following rules: 


1. An N_ Port requesting Class 1 service is 
required to have logged in with the Fabric 
and the N Port(s) with which it intends to 
communicate, either implicitly or explicitly. 
To login explicitly, the requesting N_ Port 
shall use Fabric and N_Port Login protocols 
(See “23 Login and Service Parameters”). 
(Login) 

2. The Fabric is responsible for establishing a 
Connection at the request of an N Port and 
retaining it until one of the communicating 
N_ Ports explicitly requests the Connection to 
be removed. To establish or remove the 
service, the requesting N_Port shall use the 
Class 1 Delimiters as specified in 22.1.3. 
(Dedicated Connection through Connection 
Sub-Fabric) 

3. The N Port requesting the Connection shall 
not transmit additional frames for that 
Sequence within the Connection, after the. 
frame that requests the Connection, until it 
receives confirmation through ACK from the 
destination N Port. Once the Connection is 
confirmed, only frames for that Connection 
shall be sent until the Connection is 
removed. (Dedicated Connection confirma- 
tion) 

4. A destination N Port shall provide a confir- 
mation to the Source through ACK, for each 
valid frame received, if mutually agreed to 
during N Port Login. (See 22.1.5) 
(end-to-end confirmation) 

5. The transmitter shall increment SEQ CNT 
field of each successive frame transmitted 
within a Sequence. The Fabric shall guar- 
antee delivery of the frames at the receiver 
in the same order of transmission within the 
Sequence. (See 24.11.4) (sequential delivery) 

6. An N Port is allowed to perform multiple 
Exchanges concurrently on an established 
Connection. The WN Port initiating the 
Exchanges shall assign unique OX_ID to 
each Exchange. (See 24.3). (concurrent 
multiple Exchanges) 


7. The Fabric does not exercise any flow 
control. Communicating N_Ports are respon- 
sible for the flow control. ACK frames are 
used to perform the flow control. (See 
22.1.5) (end-to-end flow control) 

8. The Fabric may reject a request for Class 1 
service or issue a busy with a valid reason 
code. Otherwise, once the service is estab- 
lished, the Fabric shall not interfere with the 
Connection. (See 20.3.3.1) (Fabric reject or 
busy) 

9. The destination N Port specified in the 
Connection-request frame may respond with 
a busy or a reject with a valid reason code 
to this frame only. Once the service is 
established, the destination N_ Port shall not 
issue busy but may issue a reject. (See 
20.3.3.1) (N_Port busy or reject) 

10. The source of any frame transmission shall 
use only the address of the N Port with 
which it has established the Connection. 
(established address) 

11. The Credit established during the Login pro- 
tocol by interchanging service Parameters 
shall be honored. (See 25.3) Class 2 and 
Class 3 share the Credit for connectionless 
service. (See 25.3) (Credit) 

12. The Fabric shall guarantee full bandwidth 
availability to the connected N_ Ports. (band- 
width) 

13. Frames are tracked on an (OX_ID or 
RX_ID)|JSEQ ID|ISEQ CNT basis. (tracking) 

14. An N_Port or F_Port shall be able to recog- 
nize SOF delimiters of all Classes of service, 
whether or not all Classes are supported by 
the N Port and_- provide appropriate 
responses for all Classes. During a Class 1 
Connection, unless Intermix is supported, a 
Class 1 N Port shall issue a P_RJT for Class 
2 frames and discard Class 3. frames. 
(invalid Class) 


22.1.3 Class 1 delimiters : 


A Dedicated Connection is requested by trans- 
mitting a frame using an SOFc1 delimiter. SOFc1 
initiates the first Sequence; subsequent 
Sequences are initiated with an SOFi1. Frames 
within a Sequence are started by SOFn1. 


Each Sequence is terminated using an EOFt. An 
EOFdt contained in a frame terminates the 
Sequence in which the frame is sent and it also 
serves to remove the Dedicated Connection. 
(Other Sequences in progress are left in an inde- 
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terminate state.) All frames other than the last 
frame within a Sequence are terminated by 
EOFn. 


22.1.4 Class 1 frame size 


The size of a frame using the SOFc1 delimiter is 
limited by the smaller value of the maximum 
Data Field size supported for frames with SOFc1 
by the Fabric and the destination N Port. Subse- 
quent frames, after a Dedicated Connection is 
established, are limited by the maximum Data 
Field size supported by the destination N_ Port. 


22.1.5 Class 1 flow control 


ACK frames are used to perform Class 1 
end-to-end flow control. ACK frames are started 
with SOFn1. If ACK is used to terminate a 
Sequence, it will end with EOFt. If used to termi- 
nate the service, it will end with EOFat. Other- 
wise it will end with EOFn. 


All Class 1 frames except one with SOFc1 delim- 
iter shall follow the end-to-end flow control rules. 
(See 25.4.2). The Class 1 frame with SOFct1 
delimiter shall follow the buffer-to-buffer flow 
control rules. (See 25.5.4). 


22.2 Class 2 -- Multiplex 


This operating environment provides 
Connectionless service with guaranteed notifica- 
tion of non-delivery between two N_ Ports. This 
service allows one N Port to transmit consec- 
utive frames to multiple destinations without 
establishing a Dedicated Connection with any 
specific N Port. Conversely, this service also 
allows one N Port to receive consecutive frames 
from one or more N_ Ports without having estab- 
lished Dedicated Connections with any of them. 


22.2.1 Class 2 function 


A Class 2 service is requested by an N Portona 
frame by frame basis. The Fabric, if present, 
routes the frame to the destination N Port. If the 
N Port transmits consecutive frames to multiple 
destinations, the Fabric demultiplexes them to 
the requested destinations. 


Class 2 Delimiters are used to indicate the 


requested service and to initiate and terminate 
One or more Sequences as described in 22.2.3. 
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Since Class 2 is Connectionless, the question of 
service removal does not arise. 


22.2.2 Class 2 rules 


To provide Class 2 service, the transmitting and 
receiving N Ports, and the Fabric shall obey the 
following rules: 


1. An N Port supporting Class 2 service is 
required to have logged in with the Fabric 
and the N_ Port(s) with which it intends to 
communicate, either explicitly or implicitly. 
To login explicitly, the requesting N_ Port 
shall use Fabric and N_ Port Login protocols. 
(See “23 Login and Service Parameters”). 
(Login) 

2. The Fabric does not establish a Connection 
between communicating N_Ports. The Fabric 
routes the frames through Connectionless 
Sub-Fabric. To obtain Class 2 service from 
the Fabric, the N_Port shall use the Class 2 
Delimiters as specified in 22.2.3. 
(Connectionless service) 

3. A given N Port is allowed to send consec- 
utive frames to different destinations and the 
Fabric is responsible to deliver them or 
inform the Source of its inability to deliver 
(See 22.2.3). This enables an N_Port to mul- 
tiplex multiple Sequences to single or mul- 


tiple destinations concurrently. 
(demultiplexing and concurrent multiple 
Sequences) 


4. If the Fabric is unable to deliver the frame to 
the destination N_ Port, then the Source is 
notified of each frame not delivered by an 
F_ BSY or F_RuJT frame from the Fabric with 
corresponding D_ID, S_ID, OX_ID, RX_ID, and 
SEQ CNT. The Source is also notified of 
frames not processed by the destination 
N Port by P_BSY or P_RuJT. (non-delivery) 

5. A given N Port may receive consecutive 
frames from different Sources. Each Source 
is allowed to send consecutive frames for 
one or more Sequences. (multiplexing) 

6. A destination N_ Port shall provide a confir- 

- mation to the Source for each valid frame 
received, if mutually agreed to during the 
N_ Port Login. As in Class 1, the destination 
N Port shall use ACK for the confirmation 
(see 22.2.5). If unable to deliver ACK, the 
Fabric shall return a BSY or RudT. 
(end-to-end confirmation) 
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7. The transmitter shall increment SEQ CNT 
field of each successive frame transmitted 
within a Sequence. However, the Fabric may 
not guarantee delivery to the destination in 
the same order of transmission. The 
receiving N_ Port shall make the frames 

~ available to the ULP in the sequential order. 
(See 24.11.4) (non-sequential delivery) 

8. The Frontend F_Port of the Fabric exercises 
buffer-to-buffer flow control with the transmit- 
ting N_Port and so does the Backend F_Port 
with the receiving N_ Port. End-to-end flow 
control is performed by communicating 
N Ports. ACK frames are used to perform 
end-to-end flow control and R_RDY is used 
for buffer-to-buffer flow control. (dual flow 
control) 

9. A busy or reject can be issued by an F_Port 
or the destination N_Port with a valid reason 
code. (See 23.6, 23.5, 20.3.3.1, and 20.3.3.2) 
(busy/reject) 

10. The Credit established during the Login pro- 
tocol by interchanging Service Parameters 
shall be honored. (See 25.3 for more on 
Credit.) (Credit) 

11. Frames are tracked on an S_ID|\(OX_ID or 
RX_ID)|ISEQ_ID|ISEQ CNT basis. (tracking) 

12. An N_ Port or F_Port shall be able to recog- 
nize SOF delimiters of all Classes of service, 
whether or not all Classes are supported by 
the N Port, and provide appropriate 
responses for all Classes. A Class 2 N Port 
shall issue a P_RJT or F_RJT for Class 1 
frames and discard Class 3 frames. (invalid 
Class) 


22.2.3 Class 2 delimiters 


Sequences are initiated by transmitting a frame 
started by an SOFi2. Subsequent frames within 
a Sequence are started by an SOFnz. A 
Sequence is terminated with a frame ended by 
EOFt. All frames other than the last frame within 
the Sequence are terminated by an EOFn. 


22.2.4 Class 2 frame size 


The size of each frame transmitted is limited by 
the smaller value of the maximum Data Field 
size supported by the Fabric or by the receiving 
N Port. Each frame is routed through the Fabric, 
if present, as a separate entity. 


22.2.5 Class 2 flow control 


Class 2 service uses both buffer-to-buffer and 
end-to-end flow controls. R_RDY (Receiver 
Ready) is used for buffer to buffer flow control. 
R_RDY is transmitted by the Fabric entry point to 
the N Port originating the Class 2 frame to 
permit transmission of the next frame from the 
Originating N Port. R_RDY is transmitted by the 
destination N Port to the Fabric exit point to 
permit delivery of the next frame to that destina- 
tion N_ Port. 


ACK frames are used to perform end-to-end flow 
control. ACK frames shall begin with SOFn2. 
ACK response to the last Data frame of a 
Sequence shall end with EOFt. Otherwise it will 
end with EOFn. 


All Class 2 frames shall follow the buffer-to- 
buffer flow control rules. (See 25.5.4). 


22.3 Class 3 -- Datagram 


This operating environment provides 
Connectionless service without any notification 
of non-delivery (BSY or RJT), delivery (ACK), or 
end-to-end flow control between two N_ Ports. 
The Fabric is allowed to discard Class 3 frames 
without any notification to the transmitting 
N Port. This service allows one N Port to 
transmit consecutive frames to multiple destina- 
tions without establishing a “Dedicated Con- 


nection” with any specific N Port. Conversely, | 


this service also allows one N Port to receive 
consecutive frames from one or more N_ Ports 
without having established Dedicated Con- 
nections with any of them. 


22.3.1 Class 3 function 


A Class 3 service is requested by an N Port ona 
frame by frame basis. The Fabric, if present, 
routes the frame to the destination N_Port. If the 
N Port transmits consecutive frames to multiple 
destinations, the Fabric demultiplexes them to 
the requested destinations. 


Class 3 Delimiters are used to indicate the 
requested service and to initiate and terminate 
one or more Sequences as described in 22.3.3. 
Since Class 3 is Connectionless, the question of 
service removal does not arise. 
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22.3.2 Class 3 rules 


To provide Class 3 service, the transmitting and 
receiving N Ports, and the Fabric shall obey the 
following rules: 


1. An N Port supporting Class 3 service is 
required to have logged in with the Fabric, 
either explicitly or implicitly. To login explic- 
itly, the requesting N Port shall use Fabric 
Login protocol. N_ Port Login is optional for 
Class 3. (See “23 Login and Service 
Parameters”) (Login) 

2. The Fabric does not establish or retain a 
Connection between communicating N_Ports. 
The Fabric routes the frames’ through 
Connectionless Sub-Fabric. To obtain Class 
3 service from the Fabric, the N_Port shall 
use the Class 3 Delimiters as specified in 
22.3.3. (Connectionless service) 

3. A given N Port is allowed to send consec- 
utive frames to different destinations. This 
enables an N Port to multiplex multiple 
Sequences to single or multiple destinations 
concurrently. (demultiplexing and concurrent 
multiple Sequences) 

4. If the Fabric is unable to deliver the frame to 
the destination N Port, the frame is dis- 
carded and the Source is not notified. If the 
destination N Port is unable to receive the 
frame, the frame is discarded and the 
Source is not notified. (non-delivery) 

5. A given N Port may receive consecutive 
frames from different Sources. Each Source 
is allowed to send consecutive frames for 
one or more Sequences. (multiplexing) 

6. A destination N Port shall not provide confir- 
mation (ACK) to the Source for any valid 
frame received. (end-to-end confirmation) 

7. The transmitter shall increment SEQ CNT 
field of each successive frame: transmitted 
within a Sequence. However, the Fabric may 
not guarantee delivery at the receiver in the 
same order of transmission. The receiving 
N Port shall make the frames available to 
the ULP in the sequential order. (See 
24.11.4). (non-sequential delivery) 

8. The Frontend F_Port of the Fabric exercises 
buffer-to-buffer flow control with the transmit- 
ting N_ Port and so does the Backend F_Port 
with the receiving N_Port. R_RDY is used for 
buffer-to-buffer flow control. (See 22.3.5) 
(buffer to buffer flow control) 

9. Neither the F_Port nor N Port shall issue 
busy or reject. (busy/reject) 
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10. The Fabric Credit is used for buffer to buffer 
flow control. N_Port Credit is not used. (See 
25.3) (Credit) 

11. Frames are tracked on an S_ID||(OX_ID or 
RX_ID)ISEQ_IDIISEQ CNT basis. (tracking) 

12. An N_Port or F_Port shall be able to recog- 

nize SOF delimiters of all Classes of service, 

whether or not all Classes are supported by 
the N Port, and_ provide appropriate 
responses for all Classes. A Class 3 N_ Port 
shall issue a P_RJT or F_RJT for Class 1 and 
Class 2 frames. (invalid Class) 


22.3.3 Class 3 delimiters 


Sequences are initiated by transmitting a frame 
started by an SOFi3. Subsequent frames within 
a Sequence are started by an SOFn3. A 
Sequence is terminated with a frame ended by 
EOFt. All frames other than the last frame within 
the Sequence are terminated by an EOFn. 


22.3.4 Class 3 frame size 


The size of each frame transmitted is limited by 
the maximum Data Field size supported by the 
Fabric and by the receiving N_ Port. Each frame 
is routed through the Fabric, if present, as a sep- 
arate entity. 


22.3.5 Class 3 flow control 


Class 3 uses only buffer to buffer flow control 
with R_RDY. End-to-end flow control is not sup- 
ported. 


All Class 3 frames shall follow the buffer-to- 
buffer flow control rules. (See 25.5.4). 


22.4 Intermix 


Intermix is an option of Class 1 service which 
allows interleaving of Class 2 and Class 3 
frames during an established Class 1 Connection 
between two N Ports. During a Class 1 Con- 
nection, an N Port capable of Intermix may 
transmit and receive Class 2 and Class 3 frames 
interleaved with Class 1 frames. The N_Ports on 
Class 1 Connection may also transmit and 
receive Class 2 or Class 3 frames with Class 1. 
Support for the Intermix option of Class 1 service 
is specified during Login. An N Port must be 
able to receive intermixed frames before it is 
allowed to transmit intermixed frames. 
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In a point-to-point topology, both interconnected 
N Ports shall be required to support Intermix if 
Intermix is to be employed. In the presence of a 
Fabric, both the N Port and the Fabric Port 
(F_Port) shall be required to support Intermix if 
Intermix is to be employed. Fabric support for 
Intermix requires that the full Class 1 bandwidth 
during a Dedicated Connection be maintained. 
Intermix permits the unused Class 1 bandwidth 
for transmission of Class 2 and Class 3 frames. 


22.4.1 Fabric management 


If an exit F_Port receives a Class 2 frame while 
the destination N_ Port is engaged in a Dedicated 
Connection and either the F_Port or the destina- 
tion N_Port do not support Intermix, an F_BSY is 
returned to the source N Port of the frame. If an 
exit F_Port receives a Class 3 frame while the 
destination N Port is engaged in a Dedicated 
Connection and either the F_Port or the destina- 
tion N_ Port do not support Intermix, the frame is 
discarded. 


During an established Class 1 Connection with 
Intermix supported, Class 1 frames have priority 
over Class 2 or Class 3 frames. Class 2 and 
Class 3 frames shall be interleaved during a 
Class 1 Connection only if there is no backlog of 
Class 1 frames en route. Although an F_Port 
and attached N Port both support Intermix, the 
F Port may choose to transmit F_BSY to a Class 
2 frame or discard a Class 3 frame while the 
N_ Port is engaged in a Class 1 Connection. 


The Fabric shall provide adequate buffering for 
an incoming Class 1 frame while a Class 2 or 
Class 3 frame is being transmitted during a 
Class 1 Connection. The extent of buffering 
needed is dependent on the manner in which a 
Class 2 or Class 3 frame in transit is managed: 


— to successfully complete a Class 2 or 3 
frame in transit, an incoming Class 1 frame 
needs to be buffered to the extent of the 
maximum Class 2 or Class 3 frame size, or 

— if a Class 2 or Class 3 frame is being 
aborted (EOFa) on receipt of a Class 1 frame, 
the Class 1 frame needs to be buffered to 
the extent of the time required to append an 
EOFa to the Class 2 or 3 frame in transit. 


22.4.2 Intermix rules 


An N Port pair shall have a Class 1 Connection 
established for the Intermix rules to be appli- 
cable to them. To provide an Intermix service, 
the Fabric and the receiving and transmitting 
N_ Ports shall obey the following rules: 


1. An F_Port or an N Port shall provide the 
service parameter as a receiver to indicate 
its Intermix capability to the transmitting 
Port. (receiver service parameter) 


2. An N_ Port which supports Intermix may 
transmit Class 2 and Class 3 frames during a 
Class 1 Connection intermixed with Class 1 
frames of that Connection if the Fabric entry 
F Port supports Intermix. (transmit Intermix) 


3. An N Port which supports Intermix may 
receive Class 2 and Class 3 frames during 
Class 1 Connection intermixed with Class 1 
frames of that Connection if the Fabric exit 
F Port supports Intermix. (receive Intermix) 


4. In a point-to-point topology, an N_ Port which 
supports Intermix may transmit and receive 
Class 2 and Class 3 frames during Class 1 
Connection intermixed with Class 1 frames if 
the other N Port supports Intermix. (point- 
to-point Intermix) 


5. If the destination is busy servicing Class 1 
frames, an exit F_Port may issue a busy to a 
Class 2 frame. (exit F_Port busy) 


6. During Class 1 Connection, if an entry F_Port 
receives a Class 2 or Class 3 frame from the 
attached N Port but does not support 
Intermix, it shall reject or discard the frame. 
If the frame is Class 2, the reason code shall 
be provided in the reject frame. Class 3 
frame shall be discarded without any 
response to the sender. (entry F_Port reject) 


7. During Class 1 Connection, if an exit F_Port 
receives a Class 2 or Class 3 frame but does 
not support Intermix, it shall reject or discard 
the frame. If the frame is Class 2, the 
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reason code shall be provided in the reject 
frame. Class 3 frame shall be discarded 
without any response to the sender. (exit 
F Port reject) 


8. The Fabric shall guarantee full Class 1 band- 
width during a Dedicated Connection. Class 
2 and Class 3 frames shall flow only on the 
unused Class 1 bandwidth. (bandwidth 
sharing) 


9. Class 1 frames have priority over Class 2 
and Class 3 frames. Class 2 and Class 3 
frames may be intermixed only when there 
is no backlog of Class 1 frames. The F_ Port 
may issue F_BSY to a Class 2 frame and 
discard a Class 3 frame. (Class 1 preced- 
ence) 


10. The Fabric may cause a delay and displace 

‘a Class 1 frame in time due to the Intermix. 

This delay is limited to the maximum Class 2 

or 3 frame size. The latency due to this 

delay is transparent to the transmitting 

N Port. The Fabric shall guarantee the 

integrity and delivery of Class 1 frames. 
(Class 1 frame skew and integrity) 


22.4.3 Intermix delimiters 


Intermix does not impose any additional delim- 
iters. 


22.4.4 Intermix frame size 


The size of each Class 1, Class 2 or Class 3 
frame is governed by the limitations of each 
Class individually. Intermix does not impose any 
additional limitation on the frame size. 


22.4.5 Intermix flow control 
The flow control for each Class is governed sep- 


arately by individual Class. Intermix does not 
impose any additional rules on flow control. 
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23 Login and Service Parameters 


23.1 Introduction 


The Login procedure is a method by which an 
N Port establishes its operating environment 
with a Fabric, if present, and other destination 
N Ports with which it communicates. Fabric 
Login and destination N Port Login are both 
accomplished with the same procedure using 
different Destination Identifiers (D_IDs). 


Explicit Login is accomplished using the LOGI 
Link_Data frame Sequence to transfer the 
Service Parameters (contained in the Data 
Field) of the N Port initiating the LOGI 
Exchange. The Frame Content is the same 
for Fabric Login and destination N_ Port 
Login except for the Destination Identifier 
(D_ID). The Accept (ACC) contains the 
Service Parameters of the Responder (con- 
tained in the Data Field). 


implicit Login is a method of defining and speci- 
fying the Service Parameters of destination 
N_ Ports by means other than the explicit 
use of the Login Exchange. Specific 
methods of implicit Login are not defined in 
this document. 


When Login is referred to throughout other 
sections of this document, either the explicit or 
implicit procedure is acceptable. Implicit Login 
is assumed to provide the same functionality as 
Explicit Login. Explicit Login permanently 
replaces previous Service Parameters and ini- 
tializes the Credit_CNT and Fabric Credit_CNT. 


Typically explicit Fabric Login is performed 
during the initialization process under the 
assumption that a Fabric is present. The first 
explicit Login is directed to the Fabric using the 
well-known Fabric address (ie. Fabric F_Port at 
hexadecimal ‘FFFFFE’). It is mandatory for all 
Fabric types to support the Login procedure. An 
N Port may use binary zeros if its physical 
address identifier is unknown, or it may use its 
last known physical address identifier in the 
LOGI frame as its S_ID. 


Login with the Fabric provides the N_ Port with 
Fabric characteristics for the entire Fabric as 
defined in the Fabric’s Service Parameters. The 
Service Parameters specified by the N _ Port 
provide the Fabric with information regarding the 
type of support the N_Port requires. The Service 
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Parameters also include a 64-bit 
World wide Name. During the Fabric Login pro- 
cedure the Fabric may optionally define the 
N Port’s physical address identifier within a 
system configuration. 


Destination N Port Login provides each N_ Port 
with the other N Port’s Service Parameters. 
Knowledge of a destination N Port’s receive and 
transmit characteristics is required for data 
Exchanges. Service Parameters of destination 
N Ports are saved and used when communi- 
cation with those N_ Ports is initiated. Saving the 
Service Parameters of destination N Ports with 
which an N_Port communicates requires N_Port 
resources. These resources can be released 
using the destination N Port Logout procedure. 


If an N_ Port desires to explicitly reLogin after a 
Login has been previously performed, the initi- 
ating N_Port shall quiese other active Sequences 
that it initiated with the destination N_ Port prior 
to performing reLogin, otherwise, Credit_CNT 
values are unpredictable. If an N Port receives 
a Login request while another Sequence is 
active which was initiated from the requesting 
N_ Port, it may reject the Login request using an 
LA_RuT (Application Reject). 


23.1.1 Applicability 


Login with the Fabric is required for all N_ Ports, 
regardless of Class of Service supported. For an 
N Port which supports Class 1 or Class 2 
Service, an N Port is required to Login with each 
N Port with which it intends to communicate 
(destination N_ Port Login). Destination N_ Port 
Login is optional for N Ports supporting only 
Class 3 Service. 


23.2 Fabric Login 


Fabric Login accomplishes five functions: 


1. Determines the presence or absence of a 
Fabric. 


2. If a Fabric is present, it provides a specific 
set of operating characteristics associated 
with the entire Fabric. | 


3. If a Fabric is present, it may optionally 
assign or confirm the native Source Identifier 


(S_ID) of the N Port which 
Login. 


initiated the 


4. If a Fabric is not present, a P_RJT response 
indicates that the requesting N Port is 
attached in a point-to-point topology. 


5. Initializes the buffer-to-buffer Credit_CNT. 


23.2.1 Explicit Fabric Login 


The explicit Fabric Login procedure requires 
transmission of a Login (LOGI) Link_Data frame 
by an N Port with a Destination Identifier (D_ID) 
of the well-known Fabric F_Port address and a 
Source Identifier (S_ID) of binary zeros or its last 
known native address identifier (X). If the S_ID 
value used is zero, the F_Port shall assign a 
Fabric unique S_ID to the N Port in the ACC 
reply Sequence. If the S ID = X is invalid, the 
F Port responds with an F_RuJT indicating invalid 
S_ID. On receiving F_RJT in response to S_ID 
= X, the N_Port shall retry the LOGI Sequence 
with an S_ID of zero. 


If the Fabric does not support native address 
identifier assignment, the N_ Port shall assign its 
native address identifier by another method not 
defined in this Standard. The Data Field of this 
Link_Data frame contains the Service Parame- 
ters of the N_ Port transmitting the LOGI frame. 
N_Port Service Parameters are defined in 23.5. 


The normal reply Sequence to a LOGI Link_Data 
frame by a Fabric is an Accept (ACC) Link Data 
frame Sequence with a Destination Identifier 
(D_ID) assigned to the N_Port by the Fabric and 
a Source ldentifier (S_ID) of the well-known 
Fabric F_Port address. The Data Field of the 
ACC contains the Service Parameters of the 
Fabric. Fabric Service Parameters are defined 
in 23.6. 


23.2.1.1 Table legend 


The following meanings are associated with 
table 42: 


— the Response/Reply Seq column identifies a 
Link_Control response, or a Link_Data frame 
transmitted in response to the LOGI frame 
directed to the Fabric Controller. More than 
one frame is possible in response. 

— the Normal/Abnormal column identifies the 
frame response as expected (Normal) or 
unexpected (Abnormal). The Normal 
responses to LOGI for Class 1 and 2 is 
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R_RDY primitive, ACK_1, and ACC. This 
assumes no busy or reject conditions in the 
presence of a Fabric (Abnormal). The 
Normal responses to LOGI for Class 3 is 
R_RDY primitive and ACC. 

— the D_ID and S _ ID columns specify the value 
of the corresponding field in the response 
frame received by the N Port transmitting 
the LOGI frame. 

— the Indication column provides a_= short 
summary of the possible conditions associ- 
ated with a particular response. 

— the N_ Port Action column specifies the 
action for the N Port transmitting the LOGI 
frame to take based on the’ response 
received. 


23.2.2 Responses to Fabric Login 


Table 42 describes the set of possible responses 
to Fabric Login. The LOGI frame transmitted 
contains a D_ID of Fabric F_Port and an S_ID of 
binary zeros or X. Further description of the 
response primitive or frame is found in clause 
20. These responses are characterized by the 
following: 


— Response 1 is possible from an N Port or 
Fabric. 


— Response 2 is from a Fabric. The D_ID and 
S_ID values correspond to the values in the 
LOGI frame (also for responses 4 and 5). 


— Response 3 completes Fabric Login. The 
N_ Port S_ID is either assigned or confirmed 
as X. 


— Response 4 indicates that the Fabric is busy. 


— Response 5 indicates a Fabric reject. If 
Class is not supported, retry Login with 
another Class. If S_ID is invalid, then retry 
Login with an S_ID of binary zeros. For 
other reject reasons, the N Port. shall 
respond accordingly. 


— Response 6 indicates a point-to-point attach- 
ment without a Fabric present. The address 
identifiers for DID and S_ID may or may not 
be assigned. The N Port shall perform des- 
tination N Port Login using the assigned 
address identifiers, if present. 


— Response 7 indicates a point-to-point attach- 
ment without a Fabric present. The N Port 
shall respond according to the action and 
reason code of the P_RuJT. 
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| — Response 8 indicates a point-to-point attach- | lower, then it shall wait for a LOGI from the 
| ment and a collision with a LOGI from the | attached N_ Port. — See 23.5.10, 
| attached N Port. The N Port shall compare | “World wide Name” for a description of 
| the values of the World_wide Names con- | World wide Names. see 23.3.2.3 for a 
| tained in the Service Parameters of the Data | description of point-to-point destination 
| Fields of its Parameters and that of the LOGI | N Port Login. | 

| received. If its value is higher, then it shall 
| 


retransmit the LOGI frame. If its value is | — Response 9 indicates that a Link error has 


| occurred. 


Table 42. Responses to LOGI frame - Fabric Login 


| — | N_Port Action 


_ 


Responsej Normal(N) 
Reply Seq oo 
1.R_RDY 
- Class 2 or 3 
- successful frame 
- Wait for Reply 
Data frame Sequence 


delivery to F_Port 
or N_ Port 
3.ACC F_ Port - Fabric Login complete - Perform destination 
N Port Login 
4.F BSY (AB) X or 0 F Port - Fabric present - retry later 
- Fabric Busy 
(AB) 


- LOGI frame has been 
received 
5.F_ RJT X or 0 F Port - Fabric present 
- reason code 


= invalid Class - select next Class 
= invalid S ID - reLogin with S_ID = 0 
other - respond accordingly 


6.P_BSY (AB) X or 0 Yor 0 - N_Port Busy - perform N_ Port Login 
- no Fabric 


7.P_RJT (AB) | Xord Y or 0 - no Fabric 
- reason code 
= invalid Class - select next Class 
invalid D_ID - perform N_ Port Login 
other - respond accordingly 


8.LOGI (AB) F Port Zoro - Collision with other - respond with P_RJT 
N_ Port (D_ID Addr error) 
- compare 
World_wide_Names 
- if xmit > rec’d 
retransmit LOGI 
- if xmit < rec’d 
wait for LOGI 


- error - retry after 
Sequence timeout 


an eee ES ED ES NS SE SR RN ed memes enn RY NOY ARES REE ED ee Een eet eS <a ene ON EN eee ceTneme ee ——— 
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23.2.3 SOF delimiters 


Since the Fabric may not support all three 
Classes of Service, the LOGI frame may require 
retransmission with a different SOF delimiter for 
each of the following Classes: 


1. Class 1 - SOFc1 
2. Class 2 - SOFi2 
3. Class 3 - SOFi3 


Selection of the SOF delimiter is based on the 
Classes of Service supported by the originating 
N Port. The LOGI frame is transmitted and the 
appropriate action is specified in Table 42. 
When a Reject (F_RJT, P_RJT) has_ been 
received indicating incorrect Class, the next sup- 
ported delimiter on the above list is attempted 
until the Login procedure is complete or all sup- 
ported delimiter types have been attempted. If 
all supported delimiter types have been 
attempted and all have been rejected by the 
Fabric, the Fabric and N Port are incompatible 
and outside intervention is required. 


23.2.4 Frequency 


The frequency of Fabric Login is installation 
dependent based on the frequency of configura- 
tion changes which may alter the N Port 
addresses within an installation. 


If a destination N Port’s address identifier has 


changed since the last Fabric Login, the source | 


N_ Port receives a Reject Link_Response frame 
with a reason code indicating an invalid source 
address identifier. 


23.2.5 Fabric Login frame flow 


see 0.4 for examples of frame flow for Login for 
Classes 1, 2, and 3. 


23.3 N_Port Login 


Destination N_Port Login between two N_Ports is 
complete when each N Port has received the 
Service Parameters of the other N_ Port. This 
may be accomplished by either implicit or 
explicit destination N_ Port Login. 
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23.3.1 Address Identifiers 


An N Port determines its own native source 
address identifier through explicit or implicit 
Login by: 


— the Fabric, if present, 
— implicit definition, 


— assignment in the LOGI frame transmitted to 
a destination N Port attached in a point-to- 
point topology, or 


— assignment by the destination N Port 
attached in a point-to-point topology in a 
response frame. 


Address identifiers of other destination N Ports 
with which an N_ Port communicates may be col- 
lected from: 


— the Fabric, if present, 
— aname-server function, 
— implicit definition, or 


— an alternate initialization procedure. 


23.3.2 Explicit N_Port Login 


Explicit N Port Login accomplishes two func- 
tions: 


1. It provides a specific set of operating charac- 
teristics associated with the destination 
N Port 


2. Initializes the destination end-to-end 


Credit_CNT. 


23.3.2.1 Fabric present 


The destination N Port explicit Login procedure 
requires transmission of a Login (LOGI) 
Link Data frame with a Destination Identifier 
(DID = Y) of the destination N Port and a 


Source Identifier (S ID = X) of originating 


N Port. The Data Field of this frame contains 
the Service Parameters of the N_ Port originating 
the LOGI frame. N_Port Service Parameters are 
defined in 23.5. 


The normal reply Sequence to a LOGI Link_Data 
frame by an N Port is an Accept (ACC) 
Link Data frame Sequence with a Destination 
Identifier (D_ID) of the originating N Port (LOGI 
frame) and a Source Identifier (S_ID) of the 
responding N_ Port. The Data Field of the ACC 
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contains the Service Parameters of the 
responding N_Port. 


Table 43. Responses to LOGI frame - N_Port Login (Fabric present) 


Response! Normal(N) N_Port Action 
Reply Seq, Abnor(AB) 
1.R_RDY (N) N/A - Class 1(SOFc1) - wait for frame 
| - Class 2 or 3 only | 
- successful frame 
delivery to F_Port 
2.ACK_1 (N) X - LOGI frame has been - Wait for Reply 
or 
ACK_N 


received Data frame Sequence 
3.ACC (N) - Login complete 


4.F_BSY (AB) X F_Port - Fabric present - retry later 
| - Fabric Busy 


5.F_RJT | (AB) F Port - Fabric present 


- reason code 
cr_Bey | (Ae) 


= invalid D_ID - determine S_ID for Y 
7.P_RUT | (AB) 


- reattempt Login 
23.3.2.2 Responses to destination N_Port Login 


= 
> 


= other - respond accordingly 


- reason code ; 
= invalid Class - select next Class 
= other - respond accordingly 


- reason code 


= invalid parameters - correct parameters 
= other - respond accordingly 


the LOGI frame. If the N Port wishes to defer 
native address identifier assignment to the desti- 
nation N Port, the N Port transmitting LOGI 
specifies binary zeros for both S_ID and D_ID. 


See 23.2.1.1 for a description of the column 
meanings. The entries in table 43 are based on 


previous Login with a Fabric. Table 43 describes The Data Field of this frame contains the Service 

the set of possible responses to destination Parameters of the N Port originating the LOGI 

N_Port Login with a Fabric present. frame. N Port Service Parameters are defined 
in 23.5. 


23.3.2.3 Point-to-point The normal reply Sequence to a LOGI Link Data 


frame by an N Port is an Accept (ACC) 
Link_Data frame Sequence. If the LOGI frame 
contained zeros for S_ID and D_ID, then the des- 
tination N_ Port shall assign SID = R and D_ID 
= Z. If the LOGI frame specified values for S_ID 
and D_ID, the destination N_Port shall use D_ID 
X and S$_ID = Y in the ACC frame. The Data 
Field of the ACC contains the Service Parame- 
ters of the responding N_Port. 


This procedure is based on the assumption that 
response 6, 7, or 8 in table 42 was received 
during an attempted Fabric Login. The destina- 
tion N_Port explicit Login procedure requires 
transmission of a Login (LOGI) Link Data frame 
with a Destination Identifier (D_ID) of the destina- 
tion N_Port and a Source Identifier (S_ID) of orig- 
inating N Port. If the N Port transmitting the 
LOGI frame wishes to assign N Port native 
address identifiers, it does so by specifying non- 
reserved values with S ID = X and D_ID = Y of 
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Table 44. com to LOGI frame - N_Port Login (point to point) 


Response 
Reply Seq 


3.ACC 
4.P_BSY 
5.P_RJT 


- Class 1(SOFc1) 

- Class 2 or 3 only 

- successful frame 
delivery to N_ Port 


- LOGI frame has been 
received 


- Wait for Reply 
Data frame Sequence 


- reason code 
= invalid Class 
other 


- select next Class 
- respond accordingly 


- reason code 


23.3.2.4 Responses to destination N_Port Login 


See 23.2.1.1 for a description of the column 
meanings. Table 44 describes the set of pos- 
sible responses to destination N_ Port Login for a 
point-to-point configuration. 


For responses 2, 4, and 5 the responding N_ Port 
shall use the address identifiers in the corre- 
sponding LOGI frame. For responses 3 and 6 
the responding N Port shall use X and Y in the 
LOGI frame, or it shall assign R and Z if the 
LOGI frame used binary zeros for address identi- 
fiers. 


If a LOGI frame is received following trans- 
mission of LOGI, then the N_ Port shall follow the 
N_Port action defined in table 42 for response 8. 


23.3.3 SOF delimiters 


since the destination N_ Port may support any of 
three Classes of Service, the LOGI frame may 
require retransmission with a different SOF for 
each Class in the same manner described for 
Fabric Login. 


invalid parameters 
other 


- correct parameters 
- respond accordingly 


23.3.4 Frequency 


The frequency of destination N Port Login is 
installation dependent based on the frequency of 
configuration changes which may alter the 
N Port addresses within an installation. Service 
Parameters of other N Ports are retained until 
the next destination N_Port Login or until N_ Port 
Logout is performed. 


23.3.5 N_ Port Login frame flow 


See 0.4 for examples of frame flow for destina- 
tion N_ Port Login for Classes 1, 2, and 3. 


23.4 N_Port Logout 


The destination Logout procedure provides a 
method for removing Service between two 
N_ Ports. Logout releases resources associated 
with maintaining Service with a_ destination 
N Port. There is no Logout procedure for the 
Fabric. 


23.4.1 | Explicit Logout 


Logout is accomplished by transmitting a Logout 
(LOGO) Link Data frame Sequence to a destina- 
tion N Port. The Logout procedure is complete 
when the responding N Port transmits an ACC 
Link Data frame reply Sequence. 


If an N Port desires to explicitly Logout, the initi- 
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ating N_Port shall quiese other active Sequences | requesting N Port, it may reject the Logout 
that it initiated with the destination N Port prior | request using an LLA_ RJT (Application Reject). 
to performing Logout, otherwise, the state of 

other active Sequences is unpredictable. If an 23.5 N Port Service Parameters 

N_ Port receives a Logout request while another = 

Sequence is active which was initiated from the 


16 Bytes 16 Bytes 16 Bytes 8 Bytes 8 Bytes 


Class 1 Class 2 Class 3 World wide r 


Service ParameteriService Parameter|Service Parameter Name 
ee era eee See ant ean ee eens aS Se, |e Re Se een EEE fA Ree eee ere eae eee 


Figure 51. LOGI or ACC Data Field 


The first 48 bytes of the Data Field specify three Each group of sixteen byte Service Parameters 
sets of Service Parameters as shown in figure are divided into the categories as specified in 
91. The first 16-byte group specifies Service figure 52. 
Parameters for Class 1. The second 16-byte 1. Class Validity (V) 
group specifies the Service Parameters for Class . 
. Service Options (E) 
2. The third 16-byte group specifies the Service 
. Transmitter Control Flags (D) 

Parameters for Class 3. The next eight bytes 

, . Receiver Control Flags (C) 
contain the World wide Name of the N Port ; 

a ae = 7 . Receive Data Size (N) 
transmitting the Service Parameters. 
: . Concurrent Sequences (L) 


. Credit (M) 


« hi ee 1 - 
Within each group of 16-byte Service Parame _ Open Sequences per Exchange (X) 


ters, fields are defined as shown in figure 52. 


Con MD OF BR GD NM 


7 The parameters described are located in the 
Bits Payload of the Login (LOGI) Link Data request 


Word as well as the Accept (ACC) Link Data reply 
Sequence sent in reply to the Login Link_Data 
Service Transmitter request 
0 Options Control , 
VEEEEEEE EEEEEEEE | DDDDDDDD DDDDDDDD 23.5.1 Applicability 
. 0 The following table identifies Service Parameter 
Receiver Receive fields and specifies the applicability of those 
1 Control Data Field Size parameters for Class 1, 2,and 3 of N Ports and 
cececece cccccece | rrrrNNNN NNNNNNNN Ne FaP Ue: 
31 
Concurrent Credit 
2 Sequences 
rrrrrrrr LLLLLLLL | MMMMMMMM MMMMMMMM 
31 
Open Sequences Reserved 
3 per Exchange 


rrrrrrvrorv.oXXXXXXXX rrrrrrrvpvrrrrvrrrr 


Figure 52. Service Parameters 
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Table 45. Service Parameter Applicability 


Class ee 


class Valeity TO 
Oe 
[Service Options ———SSSSC*dtC 
[Service Options “Class 128 0 
TFePaversion | 
Tranemittered——SSC*dY CO 
[ xaDreassignnent Sid Od 
TRecevercu Od 
T Nponrabris SSS 
ACK Suppo 
ee 
interlock 

[ Piscard policy support «dt «dS 
[Process policy support | td 
[Revered Fai Speake 

2 

2 

Ea 


Receive Data Field 
Size 


Concurrent Sequences 
Open Sequences per Exchange 


Note: “’y” indicates yes, applicable; ”n” indicates no, not applicable 


23.5.2 Class Validity | NOTE - Service Parameter options specify FC-2 
| capability. The Link Application may further limit 
e Word 0, Bit 31 - Class Validity | values supplied during Login. 
Bit 
3 


4 23.5.3 Service Options 
Service Options (E) shall specify optional fea- 
tures of a Class of Service supported by the 
N_ Port supplying the Service Parameters. 


O ~=Invalid (Class not supported) 
Valid (Class supported) 


— 


The Class Validity bit indicates whether this 
Class is supported. If the Class Validity bit is 
zero, it indicates that this set of sixteen bytes 
shall be ignored. If the Class Validity bit is one, 
it indicates that this Class is supported. The 
Class is identified based on Class 1 = first 
sixteen-byte group, Class 2 = second sixteen- 
byte group, and Class 3 = third sixteen-byte 
group. 


Service Options (E) 
Class Options 


Reserved 
FC_PH Version 
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For Class 1: 
¢ Word 0, Bits 30-28 - Class 1 Options 


Bits 
322 
098 


000 reserved 
001 Class 1 Supported 

- Exclusive Connections 
010 Class 1 Supported 

- Intermixed Connections 


An N_ Port supporting "Exclusive Connections” 
may only transmit and receive frames from the 
N_ Port to which an existing Class 1 Dedicated 
Connection is established. Exclusive Con- 
nections” require that the Fabric transmit an 
F BSY frame, as appropriate, in response to 
frames issued by a third N Port targeted for one 
of the two N_ Ports engaged in a Class 1 Dedi- 
cated Connection. 


An “Intermixed” Dedicated Connection specifies 
that the Fabric may insert Class 2 or Class 3 
frames from a third N_ Port while a Class 1 Dedi- 
cated Connection is established provided that 
sufficient Fabric buffering is present. Frames 
between the connected N Ports may be dis- 
placed in time, but not discarded. All operating 
rules regarding Idle transmission § shall be 
adhered to by the Fabric. If the Fabric must ter- 
minate an intermixed frame to a destination 
N_Port., an EOFa may be used to terminate the 
frame being transmitted. 


Support for Intermix is optional by both an 
N_ Port and a Fabric. If the N_ Port supports 
intermixing of Class 2 and 3 frames during a 
Class 1 Dedicated Connection, it must request 
Fabric support for Intermix during Login with the 
Fabric. (See 22.4 for more discussion on 
Intermix.) 


For Class 2: 
¢ Word 0, Bits 30-28 - Class 2 Options 


These bits are currently reserved since there are 
no Class 2 options. 
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For Class 3: 
¢ Word 0, Bits 30-28 - Class 3 Options 


These bits are currently reserved since there are 
no Class 3 options. 


All Classes: 
¢ Word 0, Bits 23-16 - FC_PH Version 


These bits are encoded to represent a value 
which is mapped to a specific version of FC_PH. 


23.5.4 Transmitter Control 


Transmitter Control Flags (D) specify which pro- 
tocols, policies, or functions the Transmitter 
function in the N Port supplying the Service 
Parameters requires of the Receiver. 


Word,Bits 


Transmitter Ctl Flags (D) 


0, 15 
0, 14-0 


X_ID reassignment required 
Reserved 


* Word 0, Bit 15 - X_ID reassignment required 


— 0 no X_ID reassignment 
— 1 X_ID reassignment required 


X ID reassignment required indicates that 
the N Port supplying this parameter may 
reassign its X_ID value (either OX_ID or 
RX_ID) at certain Sequence boundaries (see 
24.4). If X_ID reassignment is required, an 
N_ Port shall transmit an Association Header 
at the beginning of the Exchange and at X_ID 
reassignment points within the Exchange. 
An N_Port which does not require X_ID reas- 
signment shall use the Association Header 
as described in 24.4. If X_ID reassignment is 
required, then XID interlock also is 
required. 


23.5.5 Receiver Control 


Receiver Control Flags (C) shall specify which 
functions are supported by the N_ Port supplying 
the Service Parameters when acting as a 
receiver of device frames. Receiver Control 
Flags specify the receiver functions supported by 
the N_ Port. 


Receiver Ctl Flags (C) 


N Port/Fabric 
ACK_N support 
X_ID transition interlock 
Discard policy supported 
Process policy supported 
Reserved 

Reserved for Fabric specific 


¢ Word 1, Bit 31 - N_Port / Fabric 


— ON Port supplying parameters 
— 1 Fabric supplying parameters 


¢ Word 1, Bit 30 - ACK_N support 


— 0 ACK_N is not supported for ACK 
— 1 ACK_N is supported for ACK 


Bit 30 specifies that the Receiver does or 
does not support ACK_N for acknowledge- 
ment of good data transmission. ACK_N 
support is applicable to Class 1 and 2, but 
not Class 3. ACK_1 is mandatory, whereas 
support for the ACK_N form of ACK is 
optional. 


If both N_ Ports interchanging Service Param- 
eters specify ACK _N support, ACK_N shall 
be used for ACK. If either N_Port does not 
support ACK_N, then both N_ Ports shall use 
ACK_1. ACK_N support includes the proc- 
essing capability to transmit as well as 
receive ACK_N frames. 


NOTE - Depending on the Credit being 
managed, ACK_N may be difficult to manage 
by the Sequence Recipient when more than 
one Sequence is active. Since only the 
Sequence Initiator is aware of the Credit 
allocated to each Sequence, the Sequence 
Recipient is unable to choose an ACK_N 
window which corresponds to the Credit 
associated with a given Sequence. 
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¢ Word 1, Bit 29 - X_ID transition interlock 


— 0 no X_ID interlock 
— 1 X_ID interlock required 


This bit indicates that the N Port supplying 
this parameter requires that an interlock be 
used during X_ID assignment or reassign- 
ment. In X_ID assignment or reassignment, 
the Sequence Initiator sets the Recipient 
X_ID value to hexadecimal ‘FFFF’ in the first 
Data frame of a Sequence and the Recipient 
supplies its X_ID in the ACK frame corre- 
sponding to the first Data frame of a 
Sequence. The Sequence Initiator shall not 
transmit additional frames until the corre- 

' sponding ACK is received. Following recep- 
tion of the ACK the Sequence _ Initiator 
continues transmission of the Sequence 
using both assigned X_ID values. 


X_ID interlock shall also be used during X_ID 
reassignment as described in 24.4. 


¢e Word 1, Bits 28-27 - Error Policy Supported 


These bits are set to specify the types of support 
possible for frame out of order conditions proc- 
essed by the Receiver N Port. The_ policy 
actively used for a_egiven Exchange and 
Sequence is specified by the FC-4 at the 
Sequence Recipient. 


Out of order detection 


In Class 1, out of order detection is straightfor- 
ward because frames arrive in the order of 
transmission. However, in Class 2 and 3, out of 
order frame delivery is possible. In order to 
simplify an N_ Port’s implementation, an N_Port 
may choose to define an “out of order window”. 
An N_Port may choose a window value of W. If 
the highest SEQ CNT received minus W is 
greater than the SEQ CNT of a missing frame, 
then an out of order condition is detected. The 
value of W is only known internally to the N_ Port. 


In either Discard or Process policy, when an “out 
of order” error is detected, the “expected” 
sequence count is saved in the ERR_SEQ field of 
the appropriate Sequence Status Block and a 
Sequence error is posted in the ERR field in the 
same Sequence Status Block for a_ given 
Exchange (OX_ID, RX_ID). Only the first error is 
saved. 
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NOTE - The error status is reported by FC-2 to 
FC-4, 


e Word 1, Bit 28 = 1 - Discard Policy Sup- 
ported 


— OQ Discard Policy not supported 
— 1 Discard Policy is supported 


Discard policy support specifies that the N_ Port 
is able to discard Data frames received following 
detection of an out of order error condition 
including the frame at which the error is 
detected. 


When the out of order condition is detected, the 
sequence Recipient notifies the Sequence Initi- 
ator by indicating Abort Sequence in the ACK 
corresponding to the frame on which the error 
was detected. All subsequent frames continue 
to be discarded and abort Sequence indicated in 
the ACK frame. See 29.7.1. 


e Word 1, Bit 27 = 1 - Process Policy Sup- 
ported 


— Q Process Policy not supported 
— 1 Process Policy is supported 


Process policy support specifies that the N_Port 


is to continue to process valid Data frames fol- 
lowing a detected out of order error condition in 
the normal manner including the frame at which 
the error is detected. See 29.7.1. 


23.5.6 Receive Data Field Size 


¢ Word 1, Bits 15-0 Receive Data Field Size 
(N) 


The Receive Data_Field Size is a _ 12-bit 
binary value (bits 15-0) which specifies the 
largest Data_Field Size for an FT_1 frame 
that can be received by the N_Port supplying 
the Service Parameters. Values less than 64 
or greater than 2112 are invalid. Values are 
required to be a multiple of four bytes. 


The maximum Receive Data Field Size is 
specified by FC-2. 
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23.5.7 Concurrent Sequences 


¢ Word 2, Bits 31-16 Concurrent Sequences 
(L) 


Concurrent Sequences shall specify the 
maximum number of Sequences that can be 
active at one time between a pair of N_ Ports. 
It shall be equal to the number of Sequence 
Status Blocks available in the N_ Port sup- 
plying the Service Parameters for tracking 
the progress of a Sequence. The maximum 
number of Concurrent Sequences that can 
be specified is 255 per N Port which may be 
allocated across all three Classes. Bits 
31-24 are reserved. 


Bits 
2222 1111 
3210 9876 


0000 OO00 = ©Reserved 
0000 0001 1 Sequence Status 
Register 


eres seer 


1111 1111 255 Sequence Status 
Registers 


For Class 1: 

The SEQ ID values shall range from 0 to (L-1), 
inclusively, where L is the value of the Concur- 
rent Sequence field. 


For Class 2 and 3: 


The SEQ ID values shall range from 0 to 255. 


23.5.8 Open Sequences per Exchange 


¢ Word 3, Bits 31-16 
Exchange (X) 


Open Sequences / 


The value of Open Sequences per Exchange 
shall specify the maximum number of 
Sequences that can be open at one time 
between a pair of N Ports for one Exchange. 
The value of X+2 specifies the number of 
Sequence Status Blocks that are maintained 
for a single Exchange. This value is used for 
Exchange and Sequence tracking. The value 
of X limits the link facility resources required 
for error detection and recovery. See clause 


29. The value of X is specified in bits 23-16. 
Bits 31-24 are reserved. 


23.5.9 Credit 


¢ Word 2, Bits 14-0 Credit (M) - the 
maximum number of outstanding frames 
awaiting a response. 


The minimum value of Credit is one. The 
Credit field specified is associated with the 
number of buffers available for holding the 
Data_Field of a frame and processing the 
contents of that Data_Field by the N_ Port 
supplying the Service Parameters. 


In order to insure data integrity, Credit pro- 
vided in ACK_N should not exceed one-half 
of the maximum size sequence count. 


Values in the Credit Field have the following 
meanings: 


Bits 
111 11 
432 1098 7654 3210 


000 0000 0000 0000 
000 0000 0000 0001 
1141 1111 1111 1110 
111 1111 1111 1111 


Infinite Buffers 
1 Buffer 


32766 Buffers 
32/67 Buffers 


Fabric F_Port Login 

When an N_ Port performs Login with the Fabric 
F Port, Credit values provided are associated 
with buffer-to-buffer Credit. The buffer-to-buffer 
Credit (M) shall be a single value repeated for 
all three Classes of Service Parameters, other- 
wise a Reject frame is transmitted in response. 
An N_Port tracks buffer-to-buffer Credit_CNT as 
a single entity for all frames subject to buffer to 
buffer flow control (see clause 25). 


Destination N_Port Login 

When an N_Port performs Login with an N_ Port, 
Credit values provided are associated with end- 
to-end Credit. The end-to-end Credit (M) shall 
be a unique and separate value for each of the 
three Classes of Service Parameters. An N_Port 
tracks end-to-end Credit_CNT as on a Class 
basis (see clause 25). Login with the Fabric 
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Controller (hexadecimal ’FFFFFD’) by an N Port 
is processed in the same manner as N Port 
Login. 


From the view of the receiver of the Service 
Parameters, in_ point-to-point N Port Login, 
buffer-to-buffer Credit_CNT is the sum of Class 2, 
Class 3, plus one (for Class 1). End-to-end 
Credit is the same as any N_ Port Login. 


23.5.10 World_wide_Name 


The World wide Name is an eight byte field. 
Bits 63-60 specify the form of the name con- 
tained in bits 59-0. The World wide Name is 
assigned at the time of manufacture or may be 
locally assigned by a system administrator. If it 
is assigned at the time of manufacture, it shall 
be unique on a world wide basis. Locally 
assigned values shall be unique for a given 
installation. See 19.4 for more information. 


0 Form 


FFFFWWWW WWWWWWWW 


WWW WI WWW WW 


1 least significant 32 bits 


WWWWWWWW WWW) WWI Wiha lt 


Figure 53. World_wide Name 
Form 


Bits 
6666 
3210 


0000 Locally assigned (bits 59-0) 
0001 = CCITT 60-bit Address (bits 59-0) 
0010 IEEE 48-bit Address (bits 47-0) 
Others = Reserved 
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23.6 Fabric Service Parameters 


When a Fabric responds to a Login Link Data 
frame Sequence, certain fields in the ACC 
Link_Data reply Sequence Data Field are ignored 
and other fields are interpreted in a different 
manner than if the reply Sequence came from 
another N_Port. 


The first 48 bytes of the Data Field specify three 
sets of Service Parameters as shown in figure 
51. The first sixteen-byte group specifies Service 
Parameters for Class 1. The second sixteen- 
byte group specifies the Service Parameters for 
Class 2 and the third sixteen-byte group speci- 
fies the Service Parameters for Class 3. The 
next six bytes specifies the World_wide Name 
which identifies the Fabric. 


Within each group of 16-byte Service Parame- 
ters, fields are defined as shown in figure 52. 


23.6.1 Class Validity 
¢e Word 0, Bit 31 - Class Validity 


Bit 
3 
1 


O Invalid (Class not supported) 
1 Valid (Class supported) 


The Class Validity bit indicates whether this 
Class is supported. If the Class Validity bit is 
zero, it indicates that this set of sixteen bytes 
shall be ignored. If the Class Validity bit is one, 
it indicates that this Class is supported. The 
Class is identified based on Class 1 = first 
sixteen-byte group, Class 2 = second sixteen- 
byte group, and Class 3 = third sixteen-byte 
group. 


23.6.2 Service Options 
Service Options (E) shall specify Class of Service 


capabilities supported or required by the Fabric 
supplying the Service Parameters. 
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For Class 1: 


¢ Word 0, Bits 30-28 - Class 1 Options 


Bits 

322 

098 

O00 reserved 

00% Class 1 Capable of Exclusive 
Connections 

010 Class 1 Capable of Intermixed 
Connections 

011 Class 1 Queued Requests supported 


Support for Queued connect-requests allows an 
N Port to transmit more than one connect- 
request while it is not involved in a Dedicated 
Connection. This allows an N Port to request 
Class 1 Dedicated Connections with multiple 
destinations on a queued basis. While the 
N Port is Connected to one destination, another 
connect-request may be processed by the Fabric 
in order to minimize connect latency. Caution 
should be observed since this technique effec- 
tively locks in the destination N Port with a 
source N_ Port which may be busy. 


¢e Word 0, Bits 30-28 - Class 2 Options 


These bits are currently reserved since there are 
no Class 2 options. 


¢« Word 0, Bits 30-28 - Class 3 Options 

These b=ts are currently reserved since there 
are no Class 3 options. 

All Classes: 

¢ Word 0, Bits 23-16 - FC_PH Version 


These bits are encoded to represent a value 
which is mapped to a specific version of FC_PH. 


23.6.3 Transmitter Control 


This field is reserved. 


23.6.4 Recelver Control 


Receiver Control Flags (C) have the following 
designations for ALL classes: | 


° Word 1, Bit 15 - N_ Port / Fabric Type 


— 1 Fabric supplying parameters 


¢ Word 1, Bits 7-0 Reserved for Fabric spe- 
cific use 


see Annex N for description of current defi- 
nitions of these bits. 


23.6.5 Receive Data_Field Size 


This field specifies the largest Data Field Size 
(N) that shall be transmitted to the Fabric. 


For Class 1: 


e the frame establishing a Class 1 Con- 
nection using an SOFct1. 


For Class 2 and 3: 


° all frames 
This is the absolute capability of the Fabric. This 


field has the same format and requirements as 
the Service Parameters for an N_ Port. 


23.6.6 Concurrent Sequences 


This field is reserved. 


23.6.7 Buffer-to-buffer (Fabric) Credit 


The buffer-to-buffer Credit (M) field specified is 
associated with the number of buffers available 
for holding Class 1 connect-request, Class 2, or 
Class 3 frames transmitted to the Fabric F_Port 
for routing. 


The buffer-to-buffer Credit (M) shall be a single 
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value repeated for all three Classes of Service 
Parameters, otherwise a Reject frame is trans- 
mitted in response. An N_ Port tracks buffer-to- 
buffer Credit_CNT as a single entity for all 
frames subject to buffer to buffer flow control 
(see clause 25). 


Values in the Credit field have the same format 
as in N Port Service Parameters. 


23./ Estimate Credit 


An estimate of the minimum Credit between an 
N Port pair for a given distance helps achieve 
the maximum bandwidth utilization of the 
channel, by continuously streaming data. The 
Credit estimate procedure is defined to accom- 
plish this purpose. 


This procedure is preceded by the Login 
between this N_ Port pair. Login determines for 
this N Port pair the maximum frame size that 
can be transmitted. 


Applicability 
The procedure is applicable to both Class 1 and 
Class 2. In Class 2, the procedure and the con- 
tinuous streaming function are limited by the 
Fabric Credit. 


Users 

The procedure shall be invoked by the ULP of 
the source N Port and responded by the ULP of 
the destination N_ Port. 


Prerequisite 

To perform this procedure for Class 1 or Class 1 
Intermix, a Class 1 Connection shall have been 
established before the Estimate Credit procedure 
is performed. If no Class 1 connection exists, 
the source N Port may establish a Connection 
by issuing a NOP frame with SOFct1. 
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23./.1 Estimate Credit procedure 
This procedure consists of following three 
request Sequences. 

1. Establish Streaming Sequence 

2. Estimate Credit Sequence 

3. Advise Credit Sequence 


The procedure is illustrated with these request 
Sequences and their respective reply Sequences 
in figure 54. | 


The procedure shall be performed for Class 1 or 


Class 2 with respective delimiters, as defined in 
clause “22 Classes of service.” 


i Establish Streaming 


_— a 


uence 
Accept (Streaming Credit = L) 


Estimate Credit (SEQ_CNT = 0) 


Estimate Credit (SEQ_CNT = 1) 


ia 


Request 
000 
2 
ens Estimate Credit (SEQCNT =) 
- 
- 
oo & PRDY (SELCNT =0) 
———. 
Request Advise Credit (Estimated Credit =M+1) 
Sequence 3 


Accapt (Revised Credit) 


where 
W+1 BL 


Figure 54. Establish Credit procedure 
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23.7.1.1 Establish Streaming Sequence 


This Sequence shall be used to obtain a Credit 
large enough to perform continuous streaming 
from a source N Port to a destination N_ Port. 
This Sequence provides an opportunity for the 
destination N Port to communicate the 
maximum Credit it can provide for the purposes 
of streaming and this temporary allocation is 
termed Streaming Credit (L). 


This Sequence shall be used between an N_Port 
pair after the N Port pair has logged in with 
each other. This Sequence may be initiated as a 
new Exchange or part of another Exchange. The 
Sequence may be initiated by the Originator or 
the Responder of the Exchange. 


1. The source shall transmit the Establish 
Streaming (ESTS) frame. 


2. The destination shall reply with an ACC 
frame. 


3. The SOF delimiter of the ESTS frame identi- 
fies the Class. 


4. The Data Field of ACC shall have the same 
format as the Service Parameters for Login. 
The Data Field shall contain Streaming 
Credit (L) allocated in Credit field of the 
appropriate Class of the Service Parameters 
for which the Estimate Credit procedure is 
being performed. The other fields shall be 
ignored by the receiver. 


23.7.1.2 Estimate Credit Sequence 


This Sequence shall be performed immediately 
following reception of the ACC in response to 
the Establish Streaming Sequence. 


1. The source N Port shall stream Estimate 
Credit (ESTC) frames consecutively until it 
receives the first ACK_1 from the destination 
N Port. The source shall not exceed the 
Streaming Credit obtained during the Estab- 
lish Streaming Sequence. 


2. If the source does not receive ACK_1 after it 
has reached the limit imposed by the 
Streaming Credit value, it shall stop 
streaming and wait for the first ACK_1 to be 
received. 


3. The size of the Data Field of the ESTC frame 
shall be the maximum allowed by the © 
Service Parameters from Login. 


4. The Data Field content shall be zeros. 


5. The SEQ CNT shall start with the appro- 
priate value for the Exchange and Sequence 
in progress and monotonically increase with 
consecutive each ESTC frame transmitted. 


6. The destination N Port shall respond with 
ACK_1 to each ESTC frame received. 


7. If the highest SEQ CNT transmitted by the 
source N_ Port at the time it receives the first 
ACK_1 is M, the number of outstanding 
frames (ie. Credit estimated for continuous 
streaming) shall equal M+1. If ACK_1 is 
received within the Streaming Credit limit (L 
> M), this value of M+1 represents the 
minimum Credit required to utilize the 
maximum bandwidth of the Fibre. If the 
ACK_1 is received after reaching the 
Streaming Credit limit (L), this value is less 
than the optimal Credit required to utilize the 
maximum bandwidth of the Fibre. 


8. The source N Port shall follow all the rules 
in closing the Sequence, by sending the last 
frame of the Sequence and waiting for all the 
ACK _‘1s to be received. 


23.7.1.3 Advise Credit Sequence 


This Sequence shall be performed immediately 
following recpetion of the ACC in response to 
the Estimate Credit Sequence. The source 
N_ Port which performed the Estimate Credit 
Sequence shall advise the destination N_ Port of 
the Estimated Credit in ADVC Data Field. The 
destination N Port shall reply using an ACC 
frame, with a revised Credit value in its Data 
Field. This value is determined by the destina- 
tion N_ Port based on its buffering scheme, buffer 
management, buffer availability and N_ Port proc- 
essing time. This is the final value to be used by 
the source N_ Port for revised Credit. 


This Sequence provides a complementary func- 
tion to Login. In contrast to Login frame, the 
ADVC frame contains the Credit it would like to 
be allocated for continuous streaming. | 


If the Estimated Credit (M+‘1) is less than or 
equal to the Streaming Credit (L), the destination 
may choose to reallocate the estimated Credit. 
If the Streaming Credit (L) is smaller than 
needed for continuous streaming, the source 
N Port is bound to run short of Credit and the 
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source N Port shall advice that value as the Esti- 
mated Credit. 


1. The source N Port shall transmit Advise 
Credit frame with the Estimated Credit 
(M+ 1). 


2. The Data Field of the ACC shall have the 
same format as the Service Parameters for 
Login. The Data Field shall contain the Esti- 
mated Credit (M+ 1) in Credit field of the 
appropriate Class of the Service Parameters. 
The other fields shall be ignored by the 
receiver. 


3. The destination N Port shall determine the 
revised Credit value. The destination shall 
determine the value based on its buffer man- 
agement, buffer availability and port proc- 
essing time and may add a factor to the 

' Estimated Credit value. This is the final 
value to be used by the source N Port for 
Credit. 


4. The destination N Port replies with an ACC 
frame which successfully completes the Pro- 
tocol. The ACC frame contains the Credit 
allocated to the source N Port. The Data 
Field of ACC shall have the same format as 
the Service Parameters for Login. The Data 
Field shall contain the final Credit in Credit 
field of the appropriate Class of the Service 
Parameters. The other fields shall be 
ignored by the receiver. | 


Asymmetry 

Since the maximum frame size is permitted to 
be unequal in forward and reverse directions, 
the Estimate Credit procedure shall be per- 
formed separately for each direction of transfer. 


Frequency 

The Estimate Credit procedure provides an 
approximation of the distance involved on a 
single path. If there are concerns that in a 
Fabric in which the length (and time) of the paths 
assigned can vary, the procedure may be 
repeated several times to improve the likelihood 
that the Estimated Credit value is valid. 


Alternatively, a source may accept the Estimated 
Credit value. If at a later time, data transfers 
are unable to stream continuously the source 
may re-initiate the Estimate Credit Procedure, or 
arbitrarily request an increase in Estimated 
Credit by using an ADVC Link Data frame. 
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24 Exchange, Sequence, and Sequence Count Management 


24.1 Introduction 

An Exchange is a mechanism for coordinating 
the interchange of information and data between 
two N Ports or nodes. This clause discusses 
Exchanges between’ N Ports. However, 
Exchanges may be managed across multiple 
related N Ports within a Node or single control- 
ling entity. Additional control is required when 
multiple Sequences for a single Exchange are 
active across multiple N_ Ports simultaneously. 


Data frame transfer 

Transfer of information between two N_ Ports is 
based on transmission of a Data frame by a 
source N Port with a _ corresponding ACK 
response frame from the destination N_ Port 
receiving the Data frame to acknowledge Data 
frame delivery. 


Sequence 

A Sequence is a set of one or more related Data 
frames transmitted unidirectionally from one 
N Port to another N Port with corresponding 
ACK frames transmitted in response to each 
Data frame. A Sequence is started by an SOFix 
and terminated by an EOFt. A Sequence is 
assigned a SEQ ID (Sequence Identifier) by the 
Sequence Initiator. A Sequence shall only be 
initiated when an N_Port holds the Sequence Ini- 
tiative for a given Exchange. 


Sequence count 

Each frame within a Sequence contains a 
sequence count (SEQ CNT) which represents the 
sequential number of each Data frame trans- 
mitted within the Sequence specified by the 
SEQ ID. The sequence count is incremented by 
one for each Data frame transmitted. The ACK 
response frame contains a Sequence count 
which is set equal to the Data frame sequence 
count to which it is responding. 
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Figure 55. Exchange - Sequence relationship 


Exchange 

An Exchange is a set of one or more related 
Sequences. Sequences for the same Exchange 
may flow in the same or opposite direction 
between a pair of N Ports but not simultane- 
ously (ie. Data flows in one direction at a time 
within an Exchange for a single N Port pair). In 
Class 1, an Exchange may span multiple Dedi- 
cated Connections. 


Therefore, an Exchange may be unidirectional or 
bidirectional. Within a single Exchange only one 
Sequence shall be active at any given time for a 
single N Port. From the standpoint of the 
Sequence Initiator, a Sequence is active for the 
period of time from the transmission of the Data 
frame initiating the Sequence until the end of the 


last Data frame of the Sequence is transmitted. 
This allows an N_Port to initate a new Sequence 
following transmission of the last Data frame of a 
Sequence before the Sequence being terminated 
has been completely processed by the Sequence 
Initiator. The Sequence Initiator is required to 
use different SEQ ID values for each of the 
streamed Sequences in order to properly track 
status. 


For tracking purposes, the Sequence Recipient is 
required to ensure that consecutive Sequences 
are processed in the same order as received. 


An Exchange is-~ assigned an_ Originator 
Exchange ID (OX_ID) by the Originator and a 
Responder Exchange_ID (RX_ID) by the 
Responder facilities within the N_ Ports specified 
by the N Port Identifiers involved in the 
Exchange. When an Exchange is originated, 
there is a binding of resources in both the Origi- 
nator and Responder. 


Since an Exchange utilizes link resources, an 
N_ Port may choose to invalidate and, subse- 
quently, reassign its X_ID value at certain 
sequence boundaries during an Exchange. An 
N Port indicates its requirement to reassign 
X_ID values though a Service Parameter during 
Login. The procedure for invalidating and sub- 
sequently, reassigning an N Port’s X_ID uses 
F_CTL bits in the Frame Header. X_ID’s may be 
invalidated at the end of a Sequence and new 
X_ID values reassigned at the start of the next 
Sequence according to the procedure discussed 
in 24.4. When the X_ID value is invalidated, an 
N Port locates its Exchange Status Block by 
using an Association Header (see 19.3). 


Sequence Initiative 

The initiative to transmit a Sequence begins with 
the first Sequence of an Exchange. At the end of 
each Sequence of the Exchange, the Initiator of 
the Sequence may transfer the initiative to 
transfer the next Sequence to the other N Port, 
or it may retain the initiative to transmit the next 
sequence. 


If the Sequence Initiative is held, it is the respon- 
sibility of the Initiator to use a different SEQ _ID 
for the next consecutive Sequence in order to 
retain appropriate Sequence status information 
in both the Initiator and Responder. 
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Operation 

An Operation is an optional grouping of one or 
more Exchanges which are associated by an 
Upper Level Protocol in order to complete a 
higher level function. An N Port may support 
multiple concurrent Sequences at the same time 
where each Sequence is associated with a dif- 
ferent Exchange. Multiple Exchanges for a given 
Operation over multiple N_ Ports are allowed. 


24.2 Applicability 
Class 1 and 2: 


For Class 1 and 2, FC-2 manages: 


— Activation and deactivation of Exchanges, 

— Initiation and termination of Sequences, 

— Assignment of Exchange _ IDs, 

— Sequence Initiative 

— Assignment of Sequence IDs, 

— Segmentation and Reassembly, 

— Sequences, 

— Sequence count of frames, and 

— Detection and notification of frame Sequence 
errors. : 


For Class 1, the Sequence Initiator assigns 
SEQ IDs from 0 to (L-1) where L is the number of 
Concurrent Sequences supplied by the destina- 
tion N_ Port. The Sequence Recipient may 
assign the SEQ ID directly to a_ Recipient 
Sequence Status Block on an indexed basis. 


A Class 1 Sequence requires a Class 1 Dedi- 
cated Connection for the duration of the 
Sequence. When the Connection is terminated, 
all active Class 1 Sequences are terminated. 


For Class 2, the Sequence Initiator may assign 
SEQ IDs from 0 to 255. The Sequence Recipient 
assigns the SEQ ID to an available Recipient 
Sequence Status Block. 


Class 3: 


For Class 3, the Sequence Initiator may assign 
SEQ IDs from 0 to 255. FC-2 manages the same 
functions as Class 1 and 2 excluding notification 
of frame Sequence errors to the Sequence Initi- 
ator. 


NOTE - FC-2 defines a suite of functions avail- 


able to an FC-4 Upper Level Protocol. There are 
more facilities than a given FC-4 may require. 
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Based on the needs of a particular protocol, 
FC-4 may choose only a subset of those func- 
tions available. 


ORIGINATOR 
Exchange 
Origination 


> assign OX_ID (RX_ID = FFFF) 


V 
Sequence Initiator 


> assigns SEQ ID 


First Sequence of Exchange 


First Frame of Sequence 


ACK_1 / ACK_N 


OX_ID = original value 
RX_ID = assigned value 


update RX_ID 


24.3 Exchange origination 


The key facilities, functions, and events involved 
in the origination of an Exchange by both the 
Originator and Responder are diagrammed in 
figure 56. 


0 E S B = Originator Exchange Status Block 
RE S B = Responder Exchange Status Block 
§ 1S B = Sequence Initiator Status Block 
SRS B = Sequence Recipient Status Block 


RESPONDER to Exchange 


> assigns RX_ID based on 
S_ID|JOX_ID 


Yv 
Sequence Recipient 


> associates SEQ ID 


Figure 56. Exchange origination 


An Exchange may be originated with a destina- 
tion N_Port following destination N Port Login. 
Login provides information necessary for man- 
aging an Exchange and Sequences such as: 
Class, the number of Concurrent Sequences, 
Credit, and Receive Data Field Size. Login and 
Service Parameters are discussed in 23.5. An 
Exchange is originated through the initiation of a 
Sequence. 


A new Exchange may be originated if two condi- 
tions are met: 


1. the originating N_ Port has an 
Originator_Exchange_ Identifier (OX_ID) avail- 
able for use, and 

2. the N_ Port is able to initiate the first 
Sequence of an Exchange based on the fol- 
lowing conditions being met: 


1. the initiating N_Port has a SEQ _ID avail- 
able for use, and 

2. the total number of active Sequences ini- 
tiated by this N_ Port does not exceed the 
number of Concurrent Sequences speci- 
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fied by the destination N Port in its 
Service Parameters. 


Exchange Originator 


When an Exchange is originated by an N Port, 
that N Port assigns an Originator Exchange_ID 
(OX_ID) unique to that N Port Identifier. An 
Originator Exchange Status Block associated 
with the OX_ID is allocated and bound to the 
Exchange and other link facilities in that N_Port 
for the duration of the Exchange. All frames 
associated with that Exchange contain the 
assigned OX_ID unless the OX_ID is invalidated 
and reassigned by the Originator. The status of 
the Exchange is tracked by the Originator in the 
Originator Exchange Status Block. 


Exchange context is identified in each frame 
transmitted by the Originator via the OX_ID and 
an F_CTL Bit designating the frame as Originator 
generated. The Originator Exchange_ID pro- 
vides the mechanism for tracking request and 
reply Sequences’ for multiple concurrent 


Exchanges which may be active at the same 
time. 


NOTE - Since the Originator assigns the OX_ID, 
assignment may be organized to provide effi- 
cient processing within the N_ Port. 


Exchange Responder 


The destination N Port is designated as the 
Responder for the duration of the Exchange. 
When the destination N Port receives the first 
Sequence of the Exchange, that N_Port assigns a 
Responder Exchange_|ID (RX_ID) associated with 
the OX_ID from a given S_ID to a Responder 
Exchange Status Block (S_ID|JOX_ID). 


The assigned RX_ID shall be transmitted to the 
Originator on the ACK frame responding to the 
last Data frame of the Sequence or earlier, if 
possible. If X_ID interlock has been specified 
during Login by the Sequence Recipient, the 
RX_ID shall be assigned in the ACK to the first 
Data frame of the Sequence. The Originator 
shall withhold additional frame transmission for 
the Sequence until the ACK is received. The 
Responder Exchange ID provides the mech- 
anism for tracking request and reply Sequences 
for multiple concurrent Exchanges from multiple 
S_IDs. 


NOTE - Since the Responder assigns the RX_ID, 
assignment may be organized to provide effi- 
cient processing within the N_ Port. 


Each frame within the Exchange transmitted by 
the Responder is identified with an F_CTL Bit 
designating the frame as Responder generated 
(Exchange context). Each frame within the 
Exchange transmitted by the Responder is iden- 
tified with the assigned RX_ID unless the RX_ID 
is invalidated and reassigned by the Responder. 
The status of the Exchange is tracked by the 
Responder in the Responder Exchange Status 
Block. 


Sequence Initiative 


The Originator facility controls the origination of 
an Exchange. The origination of an Exchange 
establishes the initiative to transmit the first 
Sequence (Sequence Initiative). Thereafter, the 
Sequence Initiator facility in either the Exchange 
Originator or Responder controls holding or 
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transferring the Sequence Initiative to the 
Sequence Recipient facility in the destination 
N Port. The Sequence Initiator facility controls 
the initiation and termination of Sequences. 


If an N_ Port initiates a Sequence without holding 
the Sequence Initiative, the receiving N_Port 
responds with a P_RJT frame which terminates 
the Sequence and indicates a reason code of 
Exchange error. 


24.3.1 Frame Characteristics 
X_ID fields 


In the first frame of an Exchange, the Originator 
sets the OX_ID to an assigned value and sets 
the RX_ID value to Hex ’FFFF’ (unassigned). 
When the Responder receives the first Sequence 
of an Exchange, it assigns an RX_ID and returns 
the RX_ID in the ACK frame sent in response to 
the last Data frame in the Sequence, or in an 
earlier ACK. 


If either N_ Port has indicated during Login that 
an XID transition interlock is required at 
Exchange ID reassignment transitions, then the 
Sequence Initiator shall not transmit the second 
Data frame of a Sequence until the corre- 
sponding ACK has been received with an 
assigned X_ID for the Sequence Recipient. The 
Originator sets the RX_ID to Hex ’FFFF’ until the 
assigned RX_ID is received. When the Origi- 
nator receives the assigned RX_ID, it sets the 
RX_ID field to the assigned value for all subse- 
quent frames. 


For all remaining frames within the Exchange, 
OX_ID and RX_ID fields retain these assigned 
values unless either the Originator or the 
Responder invalidates its X_ID value at the end 
of a Sequence. 


Exchange delimiters 


Since an Exchange is composed of one or more 
Sequences, the delimiters used for an Exchange 
are the same as those used to begin and termi- 
nate a Sequence. F_CTL Bits are used to indi- 
cate the beginning and ending Sequences of an 
Exchange. 
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24.4 X_ID reassignment 


lf an N Port has indicated during Login that it 
requires X_ID reassignment, then that N_ Port 
and any N Port communicating with it shall 
follow a specific procedure in order to reassign 
its X_ID value during an Exchange. The proce- 
dure requires the use of X_ID transition inter- 
lock, an Association Header, X_ID invalidation, 
and the new X_ID indication. 


24.4.1 X_ID transition interlock 


When an N Port inititates a Sequence with an 
N Port which has specified during Login that 
X_ID transition interlock is required and the 
Recipient’s X_ID is invalid, the initiating N Port 
shall transmit the first frame of the Sequence 
with the Recipient’s X_ID set to hexadecimal 
‘FFFF’ and shall withhold transmission of the 
second frame until the corresponding. ACK with 
an assigned X_ID has been received from the 
Recipient. The assigned X_ID is then used in all 
subsequent frames in the Sequence. 


24.4.2 Association Header 


When an N Port inititates a Sequence with an 
N Port which has specified during Login that 
X_ID reassignment is required and the Recipi- 
ent’s X_ID is unassigned, the Sequence Initiator 
shall set the Recipient’s X_ID to hexadecimal 
‘FFFF’ and shall include an Association Header. 
The Association Header shall contain the infor- 
mation known by the initiating N Port at the time 
of transmission. (see 19.3) 


NOTE - It is unnecessary for the Sequence Initi- 
ator to transmit an Association Header when the 
Initiator’s X_ID is invalid. 


NOTE - An implementation may require that both 
the Originator and Responder Association _IDs 
be known prior to initiation of an Exchange. 
Other implementations may allow dynamic 
assignment of Association IDs during’ the 
Exchange. 
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24.4.3 New X_ID 


When an N Port initiates a Sequence and its 
X_ID is being assigned or reassigned, it indi- 
cates that the X_ID is new by specifying the New 
X_ID bit in F_CTL. When a Sequence Recipient 
assigns an X_ID in place of an unassigned X_ID 
(hexadecimal ’FFFF’), it indicates that its X_ID is 
new in an ACK frame being transmitted to the 
Sequence Initiator using the New X_ID bit in 
FCT 


24.4.4 Invalidating an X_ID 


At the end of a Sequence (End Sequence bit, 
F CTL bit 19), the Sequence Initiator may invali- 
date its X_ID if it has indicated X_ID reassign- 
ment required during Login by setting the 
Invalidate X_ID bit in F_CTL. At this time the 
Sequence Recipient may also invalidate its X_ID 
using the Invalidate X_ID bit in F_CTL in the ACK 
corresponding to the last Data frame of the 
Sequence providing the Recipient has indicated 
this capability during Login. The Sequence 
Recipient shall only invalidate its X_ID if the 
Sequence Initiator has invalidated its X_ID in the 
last frame of a Sequence or the Sequence Initi- 
ative is transferred. Otherwise, the Invalidate 
X_ID bit in F_CTL is ignored by the Sequence Ini- 
tiator in the corresponding ACK. 


24.5 Sequence initiation 
Sequence Initiator 


The Sequence Initiator facility within an N_ Port 
initiates a Sequence as one step within an 
Exchange under control of the Originator or 
Responder facility within the N Port. When a 
Sequence is initiated by an N_ Port, that N_Port 
assigns a Sequence_ID (SEQ _ID) uniquely asso- 
ciated with the destination N Port. That assign- 
ment varies by Class as identified in 24.2. 


The assigned SEQ ID is bound to a Sequence 
Status Block and other link facilities in each 
N_ Port for the duration of the Sequence. All 
frames associated with that Sequence contain 
the assigned SEQ ID. The Initiator also retrieves 
the appropriate Service Parameters required for 
processing during the Sequence and associates 
those parameters with the Sequence Initiator 
Status Block for the duration of the Sequence. 


Each frame transmitted by the Sequence Initiator 
is identified by the SEQ ID and an F_CTL Bit 
designating the frame as Sequence Initiator. 
The SEQ ID provides the mechanism for tracking 
Data and Link_Control frames’ within the 
sequence. 


If either N Port has indicated during Login that 
an X_ID transition interlock is required, then the 
Sequence Initiator shall not transmit the second 
Data frame of a Sequence until the corre- 
sponding ACK has been received with an 
assigned Recipient X_ID when the Recipient’s 
X_ID is invalid. If the Sequence Initiator has 
invalidated its X_ID in its previous Sequence, 
then the new X_ID assignment is indicated by 
setting the New X_ID bit in F_CTL on the first 
Data frame of a new Sequence. The status of 
the Sequence is tracked in the Sequence Status 
Block of the Sequence Initiator. 


Sequence Recipient 


The destination N Port is designated as the 
Sequence Recipient for the duration of the 
Sequence. When the destination N_ Port 
receives the first frame of the Sequence, that 
N Port assigns a Sequence Recipient Status 
Block to the newly established Sequence. This 
Status Block is associated with the SEQ ID and 
OX_ID received if Exchange Originator, or with 
the SEQ ID and RX_ID received if Exchange 
Responder. 


The Recipient also retrieves the appropriate 
Service Parameters required for processing 
during the Sequence and associates those 
Parameters with the Sequence Status Block for 
the duration of the Sequence. The SEQ _!ID pro- 
vides the mechanism for tracking the sequence 
count of individual frames transmitted and 
received during the Sequence. 


The Sequence Recipient is the receiver of the 
Sequence and each frame transmitted by the 
Sequence Recipient is identified by the SEQ ID 
and an F_CTL Bit designating the frame as 
Sequence Recipient. 


If either N Port has indicated during Login that 
an X_ID transition interlock is required, then the 
Sequence Initiator shall not transmit the second 
Data frame of a Sequence until the Sequence 
Recipient has responded with an ACK containing 
an assigned Recipient X_ID when the Recipient’s 
X_ID is invalid. If the Sequence Recipient has 
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invalidated its X_ID in the previous Sequence, 
then the new X_ID assignment is indicated by 
setting the New X_ID bit in F_CTL on the ACK to 
the first Data frame of a new Sequence. The 
status of the Sequence is tracked in the 
Sequence Status Blocks of the Sequence Recip- 
ient. 


Active and Open Sequence 


From the standpoint of the Sequence Initiator, a 
Sequence is active for the period of time from 
the transmission of the Data frame initiating the 
Sequence until the end of the last Data frame of 
the Sequence is transmitted. The Sequence Ini- 
tiator considers the Sequence open until the 
ACK with EOFt (EOFdt) is received, or the 
Sequence is abnormally terminated. 


From the standpoint of the Sequence Recipient, 
a Sequence is active and open from the time the 
initiating Data frame is received until the EOFt 
(EOFdt) is transmitted in the ACK to the last Data 
frame, or abnormal termination of the Sequence. 


Sequence Initiative 


The Sequence Initiative begins with the Origi- 
nator of the Exchange. The Initiative is held or 
passed on the last Data frame of a Sequence. 
The Sequence Initiative is tracked in the 
Exchange Status Block in both the Originator 
and Responder facilities. The upper level pro- 
tocol dictates when the Sequence Initiative is 
held or passed. 


If the Sequence Initiative is held, the next 
Sequence transmitted shall use a_ different 
SEQ ID in order to retain appropriate Sequence 
status information in both the Initiator and 
Responder. 


End Sequence 


When the Sequence Initiator is ending the 
current Sequence, it shall set the End Sequence 
bit in F_CTL to one on the last Data frame of the 
Sequence. It may also invalidate its X_ID if 
either N Port has indicated that X_ID reassign- 
ment was required during Login by setting the 
Invalidate X_ID bit in F_CTL. If the Sequence Ini- 
tiator has indicated that it is invalidating its X_ID 
or is. transferring Sequence Initiative, the 
Sequence Recipient may also indicate that it is 
invalidating its X_ID by setting the Invalidate 
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X_ID bit in F_CTL in the ACK corresponding to 
the last Data frame of the Sequence. 


24.5.1 Frame Characteristics 
SOFxi 


The first frame of a Sequence is identified by a 
Start_of_ Frame Initiate. Each Class of Service 
has individual SOF delimiters. 


When a Dedicated Connection must also be 
established for Class 1 Service, an SOFc1 is 
used to indicate a connect-request. See clause 
24 for a discussion on establishing and removing 
Class 1 Dedicated Connections. The SOFct 
establishes a Dedicated Connection and also ini- 
tiates a Sequence. 


SEQ_ID 


Each frame (Data frame and Link_Control frame) 
in a Sequence contains the SEQ ID assigned by 
the Sequence Initiator. 


SEQ_CNT 


Each Data frame of a Sequence contains a 
sequence count (SEQ CNT) which indicates the 
order of frame transmission for that Sequence. 
The SEQ CNT on each subsequent frame is 
incremented by one. Each Link_Control frame 
transmitted in response to a specific frame con- 
tains the same SEQ ID and SEQ CNT as the 
frame to which it is responding. 


The first frame of a Sequence shall contain a 
SEQ CNT of binary zero. If back to back 
Sequences for the same X_ID occur, it is the 
responsibility of the Sequence Initiator to use a 
unique SEQ ID for each consecutive Sequence. 
This is required since unique frame identification 
is based on X_ID|JSEQ IDJSEQ CNT. Under 
certain error conditions, the Sequence Initiator is 
only able to determine where an error occurred 
by providing this unique frame identification. 


Relative Offset 


Each frame within a Sequence contains a Rela- 
tive Offset in the Parameter field. The Relative 
Offset indicates the relative displacement of 
Payload portion of the Data Field content 
(excluding optional headers) within the entire 
data transmission stream of one or more 
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Sequences within an Exchange. In contrast, 
frame sequence count represents the order of 
frame transmission, not necessarily consecutive, 
contiguous data elements. 


If FC-2 encounters a wrap condition, it is 
detected as an error condition. The Exchange is 
terminated using the Abort Exchange Protocol 
and the appropriate FC-4 within this N Port is 
notified of the ending status. 


24.5.2 Busy or Reject condition 


If destination link control facilities are not avail- 
able when the frame is received which initiates a 
Sequence, the destination N_ Port responds with 
a P_BSY frame. A P_RJT frame may also be 
transmitted in response based on invalid data in 
the content of the request. Busy reason codes 
are specified in 20.3.3.2. Reject reason codes 
are specified in 20.3.3.1. 


24.6 Sequence management 


Intermediate frames within a Sequence use the 
following F_CTL and Frame_Header fields. 


Frame_Header fields 


¢ OX_ID - as assigned, or Hex ’FFFF’ if unas- 
signed 

¢ RX_ID - Hex ’FFFF’, then as assigned 

° SEQ ID - as assigned 

¢ SEQ CNT - increments by one for each 
Data frame 

¢ Relative Offset - appropriate values 


24.6.1 Sequence timeout 


A Sequence timeout is detected if an expected 
frame is not received within the timeout period. 
A Sequence timeout normally results from a lost 
or corrupted frame. 


Sequence Initiator 


The Sequence Initiator sets a timer value for 
each Data frame transmitted. If the corre- 
sponding ACK (ACK_1 or ACK_N), or a 
Link_Response frame is not received within the 
timeout period, a Sequence timeout is detected. 
The Sequence Initiator aborts the Sequence 


using the Abort Sequence Protocol. See clause 
29 for a discussion on Sequence recovery. 


Sequence Recipient 


After a Sequence has been initiated by another 
N Port, the Sequence Recipient sets a timer 
value upon reception of each Data frame. If no 
Data frame is received during the timeout period 
before the last Data frame of the Sequence is 
received, the Sequence Recipient detects a 
Sequence timeout. When a Sequence Recipient 
detects a Sequence timeout, the Sequence is 
terminated. The Sequence status is saved in the 
associated Exchange Status Block and the 
Sequence Status Block is reintialized and avail- 
able for reuse. 


lf a Data frame is received for the terminated 
Sequence after a timeout, the Sequence Recip- 
ient responds with an ACK frame indicating that 
the Sequence was aborted by setting the Abort 
Sequence Condition bits in F_CTL. 


24.7 Sequence termination 


When a Sequence is terminated, the last Data 
frame transmitted by the Sequence Initiator is 
used to identify two conditions: 


1. Sequence initiative, and 
2. Sequence termination. 


24.7.1 Sequence initiative 


The Sequence Initiator controls which N_Port is 
allowed to initiate the next Sequence for the 
Exchange. The Sequence Initiator may hold the 
initiative to transmit the next Sequence of the 
Exchange or the Sequence Initiator may transfer 
the initiative to transmit the next Sequence of 
the Exchange. The decision to hold or transfer 
initiative is indicated by F_CTL Bit 16. 


24.7.2 Termination 


The last Data frame transmitted by the Sequence 
Initiator is indicated by setting F_CTL Bit 19 to 
one. The Sequence is terminated by either the 
Initiator or the Recipient transmitting a frame 
terminated by EOFt. The Sequence Initiator its in 
control of terminating the Sequence.  Trans- 
mission of the EOFt may occur in two ways: 


1. In Class 1 and 2, the Sequence Recipient 
transmits an ACK frame of ACK_1 or ACK_N 
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in response to the last Data frame of the 
Sequence (F_CTL Bit 19 = 1) ended by an 
EOFt. 

2. In Class 3, the Sequence Initiator transmits 
the last Data frame of the Sequence with 
EOFt. 


Class 1 


When EOFt has been transmitted or received by 
each N Port, the appropriate Exchange Status 
Block associated with the Sequence is updated 
in each N_Port to indicate that the Sequence 
was completed and whether the Originator or 
Responder facility holds the Sequence Initiative. 
Link facilities associated with the Sequence 
(including Sequence Status Block) are released 
and available for other use. 


Class 2 


Since Class 2 frames may be delivered out of 
Sequence, Sequence processing is only com- 
pleted after all frames (both Data and ACK) have 
been received and processed by the respective 
N Ports. The Sequence Recipient shall withhold 
transmitting EOFt on the last ACK in response to 
the last Data frame of the Sequence until all 
preceeding Data frames have been received, 
processed, and corresponding ACK frames 
transmitted. 


When the Sequence is completed by each 
N Port, the appropriate Exchange Status Block 
associated with the Sequence is updated in each 
N Port to indicate that the Sequence was com- 
pleted and whether the Originator or Responder 
facility holds the Sequence Initiative. Link facili- 
ties associated with the Sequence (including 
Sequence Status Block) are released and avail- 
able for other use. 


Class 3 


The Sequence Initiator transmits all Data frames 
and terminates the last Data frame of the 
Sequence with EOFt. Acknowledgment of 
Sequence completion is the responsibility of the 
Upper Level Protocol. 


When the Sequence is completed by each 
N Port, the appropriate Exchange Status Block 
associated with the Sequence is updated in each 
N Port to indicate that the Sequence was com- 
pleted and whether the Originator or Responder 
facility holds the Sequence Initiative. Link facili- 
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ties associated with the Sequence (including 
Sequence Status Block) are released and avail- 
able for other use. | 


24.7.3 Abnormal termination 


A Sequence may also be terminated abnormally 
by either the Sequence Initiator or Recipient 
(also see 29.7.1). The Sequence Initiator abnor- 
mally terminates a Sequence by using the Abort 
Sequence Protocol for: 


1. a malfunction or error detected in the Initi- 
ator N_ Port facility, 

2. failure to retransmit a frame with an EOFa 
delimiter, 

3. F_CTL Bits 5-4 set to 0 1 or 1 0 on an ACK, 
or 

4. Sequence Initiator Sequence timeout. 


The Sequence Recipient abnormally terminates 
a Sequence when a Sequence timeout has been 
detected within the N_Port, or when directed to 
terminate the Sequence by an Abort Sequence 
frame from the Sequence Initiator. 


If a Sequence Recipient has encountered a 
Sequence error prior to or at the termination of 
an active Sequence, it may also abnormally ter- 
minate a consecutive, streamed Sequence for 
the same Exchange. 


24.8 Exchange management 


An Exchange is managed as a series of 
unidirectional Data frame Sequences. The initial 
Sequence is transmitted by the Originator of the 
Exchange. Control and_ intermixing = of 
Sequences within an Exchange are identified by 
CTL Bits within the Frame Header. | 


Following the initial Sequence, subsequent 
Sequences may be transmitted by either the 
Originator or the Responder facilities based on 
which facility holds the Sequence Initiative. 


24.9 Exchange termination 


An Exchange may be terminated by either the 
Originator or the Responder. The facility termi- 
nating the Exchange indicates Exchange termi- 
nation on the the last Sequence of the Exchange 
by setting the Last Sequence bit in F_CTL on 
each frame of the last Sequence of the 
Exchange. 
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The Sequence is terminated according to normal 
Sequence termination rules. When the last 
Sequence of the Exchange is terminated, the 
Exchange is also terminated. The OX_ID and 
RX_ID and associated Exchange Status Blocks 
are released and available for reuse. 


24.9.1 Abnormal termination 


An Exchange may be abnormally terminated by 
either the Originator or the Responder by using 
the Abort Exchange Protocol. In general, recep- 
tion of a reject frame with action codes of 2 or 4 
are not recoverable at the Sequence level and 
aborting of the Exchange is probable. Other 
reasons to abort an Exchange are FC-4 protocol 
dependent and not defined within this Standard. 


24.10 Status Blocks 
Exchange Status Block 


An Exchange Status Block is a logical construct 
used to associate the OX_ID, RX_ID, D_ID and 
S_ID of an Exchange. The Status Block is used 
throughout the Exchange to track the progress of 
the Exchange and identify which N Port (or 
node) holds the initiative to transmit Sequences. 
An Exchange Status Block is created in the Orig- 
inator (OESB) and in the Responder (RESB) 
when an Exchange is originated. The Status 
Blocks are released when the Exchange is termi- 
nated. 


Sequence Status Block 


A Sequence Status Block is a logical construct 
used to track the progress of a single Sequence 
by an N Port on a frame by frame basis. The 
Status Block is created in the Sequence Initiator 
(SISB) and in the Sequence Recipient (SRSB) 
when the Sequence is initiated. The Status 
Blocks are released when the Sequence is ter- 
minated. 


24.11 Rules 


ee 


24.11.1 Exchange origination 


1. 


A new Exchange may be originated if three 

conditions are met: 

A. The originating N Port has performed 
Login with the destination N_ Port. 

B. The originating N_ Port (or node) has an 
Originator Exchange Identifier (OX_ID) 
available for use. 

C. The N Port is able to initiate a new 
sequence. 


. Each frame within the first Sequence of an 


Exchange shall set F_CTL Bit 21 to one. 


. The Originator transmits the first Data frame 


of the Exchange with its assigned OX_ID and 
an unassigned RX_ID of hexadecimal ’FFFF’ 
by setting the New X_ID bit in F_CTL. 


. The rules specified in Sequence initiation 


and termination specify the method for 
assigning and reassigning X_IDs. 


24.11.2 Sequence Initiation 


ie 


. The Sequence 


A new Sequence may be initiated if three 

conditions are met: 

A. The initiating N Port holds the initiative 
to transfer (Sequence Initiative). 

B. The initiating N_ Port has a SEQ ID avail- 
able for use. 

C. The total number of active Sequences 
initiated by this N_ Port does not exceed 
the number of Concurrent Sequences 
specified by the destination N_Port in its 
service Parameters. 


. The first Data frame of the Sequence is 


started by an SOFix (or an SOFc1 for the first 
frame establishing a Class 1 Connection). 
Initiator assigns its X_ID 
(either OX_ID or RX_ID) to its assigned value 
and indicates if it is a new assignment by 
setting the New X_ID bit in F_CTL on the first 
frame of a Sequence. 


. A new X_ID shall not be assigned after the 


first Sequence of an Exchange unless the 
previous X_ID has been invalidated. 


. The Sequence Initiator uses the Recipient’s 


X_ID value assigned by the Recipient or 
hexadecimal ’FFFF’, if unassigned. If the 
Recipient’s X_ID is unassigned and the 
Recipient requires X_ID reassignment, as 
specified during Login, the Initiator also 
transmits an Association Header. 


. When a Sequence is initiated, if the Recipi- 


ent’s X_ID is unassigned and X_ID transition 
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interlock has been specified during Login, 
the Sequence Initiator withholds transmitting 
the second frame of the Sequence until the 
Recipient X_ID is received in the ACK corre- 
sponding to the first frame is received by the 
Initiator. 


_ Frame transmission shall follow Flow Control 


Rules as specified in clause 25. 


24.11.3 Sequence management 


1 


. Each frame shall 


. Each frame. shall 


Each frame shall contain 
OX_ID, RX_ID, and SEQ_ID. 


the assigned 


. Hexadecimal ‘FFFF’ shall be used for unas- 


signed X_ID values. 

indicate the Exchange 
Context. 

indicate the Sequence 
Context. 


. Each frame shall contain a SEQ CNT which 


follows the Sequence Count rules as defined. 


. Frame transmission shall follow Flow Control 


Rules as specified in clause 25. 


. The Data Field size of each frame of the 


Sequence shall be less than or equal to: 

A. the maximum size specified by the 
Fabric (SOFc1, Class 2, or 3), if present, 
or 

B. the maximum size specified by the desti- 
nation N_ Port in the Service Parameters 
defined during Login, whichever is 
smaller. 


24.11.4 Sequence count 


Within a Data frame Sequence, SEQ CNT is used 
to identify each Data frame for verification of 


delivery. 


The following rules specify the 


sequence count of each frame of a Sequence: 


1. 


The sequence count (SEQ CNT) of the first 
Data frame of a new Sequence is binary 
zero. (lf back to back Sequences for the 
same X_ID occur, it is the responsibility of 
the Sequence Initiator to use a_ unique 
SEQ _ ID for consecutive Sequences.) 


. The sequence count of each subsequent 


Data frame is incremented by one from the 
previous Data frame. 


. The sequence count of each Link Response 


shall be set to the sequence count of the 
Data frame to which it is responding (Class 1 
and 2). 
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4. 


The sequence count of each ACK_1 frame 
shall be set to the sequence count of the 
Data frame to which it is responding. (Class 
1 and 2) 


. The sequence count of each ACK_N frame 


shall be set to the highest sequence count of 
a series of Data frames being acknowledged. 
(Class 1 and 2). See Annex M for ACK_N 
rules. 


. The sequence count shall not wrap within a 


sequence. 


24.11.5 Sequence termination 


1. 
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The Last Data frame of a Sequence shall be 
indicated by F_CTL Bit 19 set to one. 


. The Sequence Recipient shall transmit an 


ACK frame of ACK_1 or ACK_N in response 
to the last Data frame of the Sequence 
(F CTL Bit 19 = 1) ended by an EOFt (or 
EOFat) in Class 1 and Class 2. 


— Class 1 - the Sequence Recipient shall 
transmit the last ACK response after 
receiving the last Data frame. 


— Class 2 - the Sequence Recipient shall 
withhold transmission of the last ACK 
frame until all preceding Data frames 
have been received, processed, and cor- 
responding ACK frames transmitted. 


. In the last Data frame of a Sequence, the 


Sequence Initiator sets the 
— Sequence Initiative bit in F_CTL to 0 to 
hold Sequence Initiative. 


| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 


— Sequence Initiative bit in F_CTL to 1 to 
transfer Sequence Initiative. 

— Invalidate X_ID bit in F_CTL to 0 to retain 
X_ID assignment. 

— Invalidate X_ID bit in F_CTL to 1 to invali- 
date its current X_ID. 


4. If the last Data frame of a Sequence has the 


Invalidate X_ID bit set to one or transfers 

Sequence Initiative, the Sequence Recipient 

sets the 

— Invalidate X_ID bit in F_CTL to 0 to retain 
X_ID assignment in the ACK response. 

— Invalidate X_ID bit in F_CTL to 1 to invali- 
date its current X_ID in the ACK 
response. 


24.11.6 Sequence delimiters 


The following rules specify the management of 
frame delimiters within a Sequence: 


1. A Sequence shall be initiated by transmitting 


the first frame with an SOFix, or SOFc1. 


2. Intermediate frames within a Sequence shall 


be transmitted with SOFnx and EOFn. 


3. The Sequence shall be complete when an 


EOFt (or EOFdt) has been transmitted or 
received for the appropriate Sequence _ID. 


24.11.7 Exchange termination 


1. The last Sequence of the Exchange shall be 


indicated by setting F_CTL Bit 20 to one. 


2. The Exchange shall be terminated when the 


last Sequence is terminated by normal 
Sequence termination rules. 


25 Flow control management 


25.1 Introduction 

Flow Control is a FC-2 control process to pace 
the flow of frames between N_ Ports and between 
an N_ Port and the Fabric to prevent overrun at 
the receiver. Flow Control is managed using 
end-to-end Credit, end-to-end Credit_CNT, ACK 
(ACK_1 or ACK_N), buffer-to-buffer Credit, buffer- 
to-buffer Credit_CNT, and R_RDY along with 
other frames. 


Flow Control is managed between N_Ports (end- 
to-end) and/or between N Port and F_Port 
(buffer-to-buffer). Flow Control management has 
variations dependent upon the Class of Service. 


Applicability 

Class 1 uses end-to-end flow control. Class 2 
uses both end-to-end and buffer-to-buffer flow 
controls. Class 3 uses only buffer-to-buffer flow 
control. Table 47 shows the applicability of flow 
control mechanisms to each Class. 


N Port 


Class 1 & 
Class 2 / 
Class 3 
RCV 
Buffers 
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25.2 Physical flow control model 


The physical flow control model is illustrated in 
figure 57. The model consists of following phys- 
ical components: 


— Each N Port with Class 1 - and/or 
Connectionless (Classes 2and 3 combined) 
receive buffers. 

— Each F_Port to which an N Port is attached, 
with its receive buffers (Classes 2 and 3 
combined) for Connectionless Service. 
(Class 1 buffers internal to Fabric used for 
Class 1 service and Intemix are transparent 
to FC_2 flow control.) 


Buffer participation 

Buffering and transmission of Class 1 frames 
through the Fabric is transparent to FC-2. Class 
1 buffering requirements during Intermix are 
specified in FC-2 (see section 22.4, “Intermix” 
form=numonly). The use of Class 1 buffers 
during Intermix is transparent to flow control. 
Class 2 and Class 3 buffers are shared by Class 
2 and Class 3 frames. The following table sum- 
marizes the use of buffers for end-to-end and 
buffer-to-buffer flow controls. 


F Port N Port 


Class 1& 
Class 2 / 
Class 3 
RCV 
Buffers 


Figure 57. Physical flow control model 
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Table 46. Buffer participation 


Participating buffers 


Connectionless buffers Class Ves 
(Classes 2 and 3 combined) 2 


Note: ~* Participation of Class 1 buffers in the 
Fabric during Intermix is transparent to flow 
control. 


Naming convention 
The F_Port attached to the Sequence Initiator 
N_Port is referred to as Frontend F_Port and the 
one attached to the Sequence Recipient N_ Port 
as Backend F_Port. 


25.3 Credit and Credit_Count 


Credit is the number of receive buffers allocated 
and/or available to a transmitting port (an 
N_Port or an F_Port). Two types of Credits used 
in FC-2 flow control are: 


1. End-to-end Credit 
2. Buffer-to-buffer Credit 


The Credit_Count is the running count of the 
Credit that the transmitting port (the N Port or 
F Port) uses to track the number of receive 
buffers occupied. The Credit_Count shall not 
exceed the value of Credit to avoid the possi- 
bility of overflow at the receiver. Corresponding 
to two types of Credits listed above, two types of 
Credit_Counts used in FC-2 are: 


1. End-to-end Credit_Count 


Flow Control methodology and mechanism 


End-to-end 
Buffer-to-buffer 
ACK_1 or ACK_N 7 
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Table 47. Flow Control applicability 


[ves | ves | vee [No 
a 
[ves | vee | ves ft 
a 
a 
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2. Buffer-to-buffer Credit_Count 


Usage 

The N_ Port transmitting Data frames shall use 
the end-to-end Credit allocated by the receiving 
N_ Port for end-to-end flow control and manage 
the corresponding end-to-end Credit Count. 
When a port (an N_Port or an F_Port) is transmit- 
ting Data frames or Link_Control frames to the 
attached port (F_Port or N_Port respectively), the 
transmitting port shall use buffer-to-buffer Credit 
allocated by the receiving port for buffer-to-buffer 
flow control and manage the corresponding 
buffer-to-buffer Credit_ Count. 


25.3.1 End-to-end Credit 


End-to-end Credit (EE Credit) is the number of 
receive buffers in the Sequence Recipient N_ Port 
that have been allocated to a given Sequence 
Initiator N Port. End-to-end Credit represents 
the maximum number of unacknowledged or out- 
standing frames that can be transmitted without 
the possibility of overrunning the receiver at the 
Sequence Recipient N Port. End-to-end Credit is 
defined per Class per Sequence Recipient 
N Port and managed by the Sequence Initiator 
N Port. Class 1 End-to-end Credit represents 
the number of Class 1 receive buffers and Class 
2 End-to-end Credit the number of Class 2 
buffers allocated to the Sequence Initiator 
N Port. (EE Credit is not applicable to Class 3.) 
The value of End-to-end Credit allocated to the 
Sequence Initiator N Port is conveyed to this 
N_ Port through the End-to-end Credit field of the 
Service Parameters. The minimum value of End- 
to-end Credit is one (1). 


End-to-end Credit is used as a_ controlling 
parameter in end-to-end flow control. 


Connect 
request 


frame with 
SOF ct 


25.3.2 End-to-end Credit_Count 


End-to-end Credit_Count (EE _Credit_CNT) is 
defined as the number of unacknowledged or 
outstanding frames awaiting a response and 
represents the number of receive buffers that 
are occupied at the Sequence Recipient N_ Port. 
To track the number of frames transmitted and 
outstanding, the Sequence Initiator N_ Port uses 
this variable called End-to-end Credit Count 
(End-to-end Credit_CNT). 


EE Credit is obtained by a Sequence Initiator 
N Port during N Port Login from the N_ Port to 
which it is logging into. EE Credit allocated by 
the Sequence Recipient N Port forms’ the 
maximum limit for the EE Credit_CNT value. 
The EE Credit_CNT value is initially set at zero 
(0), immediately after Login. The EE Credit_CNT 
is incremented, decremented or left unaltered as 
specified by the flow control management rules 
(sections 25.4.2 and 25.5.4). The EE Credit_CNT 
shall not exceed the EE Credit value to avoid 
possible overflow at the receiver. 


The Sequence Initiator shall allocate the total 
N Port Credit associated with a Sequence Recip- 
ient among all active Sequences associated with 
that Recipient. The Sequence Initiator function 
may dynamically alter the Credit associated with 
each active Sequence as long as the total 
N_ Port Credit specified for the Sequence Recip- 
ient is not exceeded. In the event of an 
abnormal termination of a Sequence using the 
Abort Sequence Protocol, the Sequence Initiator 
may reclaim the Sequence Credit allocation 
when the Accept response has been received to 
the Abort Sequence frame. 


The N Port is_ responsible for managing 
EE Credit CNT using EE Credit as the upper 
bound on a per port basis. 


25.3.3 End-to-end Class dependency 


Allocation of EE Credit and management of 
EE Credit _ CNT have some variations dependent 
upon Class of Service. 


EE Credit allocation 


— Each Sequence Recipient N Port may allo- 
cate the same Class 1 N_ Port Credit value to 
each N_ Port it is logging into. This Class 1 


FC-PH REV 2.1, May 25, 1991 


Credit value may be the maximum support- 
able by the Sequence Recipient N_ Port. 


— Each Sequence Recipient N Port allocates 
some number of its receive buffers for Class 
2 Service to N Ports it is logging into. The 
sum of allocated Class 2 buffers may exceed 
the total number of Class 2 buffers supported 
at the Sequence Recipient N Port. This 
excess buffer allocation may not necessarily 
result in overrun. Class 2 EE Credit allo- 
cation depends upon system requirements 
which are outside the scope of this standard. 


EE Credit_CNT management 


— Since Class 2 supports demultiplexing to 
multiple Sequence Recipient N Ports, the 
Sequence Initiator N Port manages a 
Connectionless EE Credit CNT for each 
Sequence Recipient N Port currently active, 


with that Sequence Recipient N Port’s 
EE Credit as the upper bound. 
— An Class 3 N Port does not perform 


EE Credit CNT management. 


Note - Login ensures that appropriate values are 
interchanged. 


25.3.4 EE Credit management 


EE Credit management involves an _ WN Port 
establishing and revising EE Credit with the 
other N_ Port it intends to communicate with, for 
Class 1 or Class 2 or both. N_Port Login is used 
to establish and _ optionally revise these 
EE Credit values. The Service Parameters inter- 
changed during N Port provide the Class 1 
and/or Class 2 EE Credit separately in their 
respective Credit fields. 


25.3.5 Buffer-to-buffer Credit 


Buffer-to-buffer Credit (BB Credit) represents the 
number of receive buffers for Connectionless 
Service (Class 2 and/or Class 3) supported by a 
port. (N Port or F_Port). BB Credit values of the 
attached ports are mutually conveyed to each 
other during the F Port Login thorough the 
Credit field of Service Parameters. Minimum 
value of BB_ Credit that an F_Port shall support 
is one (1). 


BB Credit is used as the controlling parameter 
in buffer-to-buffer flow control. 
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25.3.6 Buffer-to-buffer Credit_Count 


Buffer-to-buffer Credit_Count (BB_Credit_CNT) is 
defined as the number of unacknowledged or 
outstanding frames awaiting R_RDY responses 
from the directly attached port. It represents the 
number of receive buffers that are occupied at 
the attached port. To track the number of 
frames transmitted for which R_RDY responses 
are outstanding, the transmitting port uses this 
variable called BB_Credit_Count. 


The transmitting port is responsible to manage 
BB Credit_CNT with BB Credit as its upper 
bound. 


25.3.7 Buffer-to-buffer Class 
dependency 


Allocation of BB Credit and management of 
BB_Credit_CNT for Connectionless Service are 
described. 


BB _ Credit allocation 

Each port allocates the total number of 
Connectionless buffers (Classes 1 and 2 com- 
bined) to the port it is directly attached to. 


BB_Credit_CNT management 
A port manages the BB _Credit_CNT with 
BB Credit as the upper bound. 


25.3.8 BB_Credit management 


BB Credit management involves a port receiving 
the BB Credit value from the port it is directly 
attached to. F_Port Login is used to accomplish 
this. The Service Parameters interchanged 
during F_Port Login provide the number of com- 
bined Class 2 and Class 3 buffers. These com- 
bined values are provided in both Class 2 and 
Class 3 Credit fields. 


25.4 End-to-end flow control 


End-to-end flow control is an FC-2. control 
process to pace the frames between N Ports. 
End-to-end flow control is used by an N_Port pair 
on Class 1 or Class 2. 


End-to-end flow control is performed with 


EE Credit_CNT with EE Credit as the eoninomne 
parameter. 
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25.4.1 End-to-end flow control model 


The end-to-end flow control model is illustrated 
in figure 58. The model includes flow control 
parameters, control variables and resources for 
a Data frame from a Sequence Initiator N_Port 
and ACK_1 or ACK_N or BSY/RuJT in response 
from the Sequence Recipient N_ Port. 


— The Sequence Recipient N Port provides a 
number of Class 1 and/or Class 2 receive 
buffers. 

— The Sequence Initiator N Port obtains the 
allocation of Class 1 and/or Class 2 receive 
buffers, as Class 1 and/or Class 2 
EE Credits, respectively. (That allocation is 
distributed among all the active Sequences 
for a specific Sequence Recipient.) 

— The Sequence Initiator N Port manages the 
end-to-end flow by managing Class 1 and/or 
Class 2 EE Credit-CNT(s). (That manage- 
ment is distributed among all the active 
Sequences for a specific Sequence Recip- 
ient.) 


The model illustrates all possible replies to the 
Data frame. The EE _Credit_CNT is decremented 
by one (1) or m depending upon the type of 
Link_Control frame received. 


SI Front-end Back-end SR 

N Port F Port F_Port N Port 
End-to-end 

Credit_CNT 


(Class 1/ Class 2) 
0 


Class 1 or Class 2 
Data frame 


——HK OO we EE RO Ee EO BO Ee TOE EMO OO Dee eT Be eee we ee 


+] 
es _BSY/F_ RJT 
-1 : 
@ 


OY [Mien teoceec eee st etene ees e een see season sessee sae 
-m | aT P_BSY / P_RJT 
achat ere lire nd Beanies 
-1 / -m | Hil | ACK 

EES. Number 

Credit of 

(Class 1/ Class 1/ 

Class 2) Class 2 
receive 
buffers 

Legend: 


m = number of valid frames acknowledged collectively 


Figure 58. End-to-end flow control model 


25.4.2 End-to-end management rules 


End-to-End management rules are described in 


this section. 


Management of EE Credit CNT is 


summarized in table 49. 


. The Sequence 


. The Sequence Initiator N_ Port is responsible 


for managing EE Credit CNT across all 
active Sequences. 

Initiator N Port shall not 
transmit a Data frame unless the allocated 
Credit is greater than zero. 


._ In Class 1 or Class 2, the initial value of the 


EE Credit_CNT is set to zero (0) during Login 
or re-Login. 


. In Class 1, the EE _Credit_CNT is set to one 


(1), on transmitting the frame with SOFc1. It 
is incremented by one (1) for each subse- 
quent Class 1 frame transmitted. 


. The EE Credit CNT incremented by one (1) 


for each Class 2 Data frame transmitted. 


. The Sequence Initiator N Port decrements 


the EE Credit_CNT by a value of one for 
each ACK_1 received and by a value of m 
for each ACK_N received where m is the 
number of valid frames received and 
acknowledged by the Sequence Recipient 
N_ Port. 


. To avoid possible overrun at the receiver, 


the Sequence Initiator N Port manages the 
EE_Credit_CNT not to exceed EE Credit. 


25.4.3 ACK_1 rules 


i 


1. 


The Sequence Recipient transmits an ACK_1 
in response to each Data frame received and 
returns the SEQ CNT of the Data frame to 
which it is responding. 


. The Sequence Recipient sets the discard bit 


in all ACK_1 frames transmitted after 
detection of a SEQ CNT error condition, 
including the frame at which the error is 
detected if the discard error policy is speci- 
fied. 


25.4.4 ACK_N rules 


The ACK_N window (maximum value of ”m’, 
the number of consecutive frames acknowl- 
edged collectively) chosen by the Sequence 
Recipient shall be less than Credit. 


Note - If the ACK_N window and the Credit 
are equal and a frame is lost, the receiver 


. ACK_N shall 


(See ACK_N 
Annex M.) 


— Sequence 
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will be waiting for the frame and the sender 
will be waiting for the ACK resulting in a 
“hang” condition. ”m less than Credit” helps 
prevent the “hang” condition unless multiple 
frames (equal to Credit minus m) are lost. 
Implementers are advised caution that ”’m 
less than Credit” does not help elimination of 
“hang” condition if Credit is collectively 
managed for all active Sequences. The hang 
condition is detected through timeout and 
rectified through Credit_Count recovery (see 
-- Heading ‘TIMEOUT’ unknown -- and 25.4.5). 


. ACK_N shall report the number of all con- 


secutive frames received within the ACK_N 
window (in Credit acknowledged field). 


. ACK_N shall include the maximum sequence 


count of consecutive frames being reported 
(in SEQ CNT field). 


. ACK_N shall be issued at the end of the 


Sequence. 
be sent on detection of a 
missing or a invalid frame. 


usage examples in appendix 


25.4.5 EE Credit recovery 


1. In Class 1 and Class 2, EE Credit can be 


recovered by Sequence Initiator when a 
Sequence is terminated, by the number of 
unacknowledged Data frames associated 
with the Sequence being terminated. Termi- 
nation may be normal or abnormal. 


. In Class 1, EE Credit may be recovered by 


the Sequence Initiator within the Sequence 
by detection of SEQ CNT discontinuity in 
ACK_1. 


. Class 1 EE Credit is also recovered when a 


Dedicated Connection is removed by either 
EOFdt or by the Link Recovery Protocol. 


. In Class 1 and 2, EE Credit may also be 


recovered by an N_Port through re-Login. 


25.5 Buffer-to-buffer flow control 


Buffer-to-buffer flow control is an FC-2 staged 
control process to pace the flow of frames. The 
buffer-to-buffer stages are: 


Initiator N Port to Front-end 


F Port 


— Back-end F_Port to Sequence Recipient 


N_ Port 
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25.5.1 Buffer-to-buffer flow control 
model | 


The Buffer-to-buffer flow control model is illus- 
trated in figure 59. The model includes flow 
control parameters, control variables for a Class 
2 or Class 3 Data frame and R_RDY as its 
response,- and the resources (Class 2 and/or 
Class 3 receive buffers) for Connectionless 
Service. All possible responses to a Class 2 or 
Class 3 Data frame are illustrated. 


— Each N_Port and F_Port provides a number 
of receive buffers for Connectionless 
Service. 

— Each N_Port obtains the allocation of receive 
buffers from the F_Port it is attached to, as 
BB Credit. Each F_Port obtains the allo- 
cation of receive buffers from the N_ Port it is 
attached to, as_ total BB Credit for 
Connectionless Service. 

— Each port manages the buffer-to-buffer flow 
by managing the BB _Credit_CNT for the 
Connectionless Service, with BB Credit as 
the upper limit. 


SI Front-end Back-end SR 

N Port F Port F_Port N Port 

BB_ BB_ BB BB_ 
Credit_CnT Credit_CNT Credit_CNT Credit_CNT 


Class 2 or Class 3 


Data frame Class 2 or Class 3 
SE ee ete ae ->\|-T Data frame 
2 Fit) S-fem emer ee ee > 
Septet: dee Werks toate ye 
R RDY 
tt — — =e ee a see ome oe 
R_RDY 
F_BSY/F_RJT P_BSY/P_RJT 
P_BSY/P_RJT ACK 
ACK PS are ee eee - 
oe —-—-- - - - = a 
mere er eee —> 
R_RDY 
—-3- eer eee ee > 
R_RDY 


BB_ RCV buffers 
Credit BB_ for 
Credit Connectionless 


Service 


Figure 59. Buffer-to-buffer flow control model 
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25.5.2 Class dependent frame flow 


Figures 60, 61 and 62 illustrate the flow of frames 
to accomplish buffer-to-buffer Control, respec- 
tively for the following cases: 


— Class 2 with delivery or non-delivery to the 
Fabric. 
— Possible responses from the F_Port or 
an N_Port within the Fabric to a Class 2 
Data frame are illustrated in figure 60. 
— Class 2 with delivery or non-delivery to an 
N_ Port. 
— Possible responses from the F_Port and 
the destination N_Port to a Class 2 Data 
frame are illustrated in figure 61. 
— Class 3. 
— Possible responses from the F_Port and 
the destination N_Port to a Class 3 Data 
frame are illustrated in figure 61. 


Si N_Pert Fabrie SR N_Pert 


Figure 60. Buffer-to-buffer - Class 2 frame flow 
with delivery or non-delivery to the 
Fabric 


SR N_Port 


Figure 61. Buffer-to-buffer - Class 2 frame flow 
with delivery or non-delivery to an 


N_ Port 
S! N_Port Fabrlo SR N..Port 
Claaa 3 
frame 
R_RDY Pe 
‘ 
. 
x 
~ 
~ 
~ 
iN 
Clase 3 
frame 
R_RDY 


Figure 62. Buffer-to-buffer - Class 3 frame flow 


25.5.3 R_RDY 


R_RDY is the pacing mechanism exclusively 
used for buffer-to-buffer flow control. For any 
Class 2 or Class 3 or Class 1 frame with SOFc‘1 
received at an F_Port or at an N Port, each port 
issues an R_RDY primitive. 
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25.5.4 Buffer-to-buffer management 
rules 


Buffer-to-buffer flow control rules are described 
in this section. Managing BB_Credit_CNT at an 
N_ Port or an F_Port is summarized in table 50. 


1. Each port is responsible for managing the 
BB Credit_CNT. 

2. Each port sets BB_Credit_CNT value to zero 
(0) during Login or re-Login. 

3. Each port increments BB_Credit_CNT by one 
(1) for each Class 2 or 3 frame transmitted 
and decrements by one (1) for each R_RDY 
received. 

4. Each port issues an R_RDY for each Class 2 
or 3 frame received. 

5. To avoid possible overrun at the receiver, 
each port manages BB Credit_CNT not to 
exceed BB Credit. 


25.5.5 R_RDY rule 


N Port and F Port transmits an R_RDY in 
response to each Class 2, Class 3 or Class 1 
frame with SOFc1 received. 


25.5.6 BB_Credit_Count reset 


BB Credit_Count is reset by an N Port on re- 
Login and after the Link Recovery Protocol has 
been performed. 


25.6 BSY / RJT in flow control 


In Class 1 end-to-end flow control, F_BSY or 
P BSY do not occur, except for a Class 1 
Request with SOFc1. In Class 2 end-to-end flow 
control, F_BSY, F_RJT, P_BSY or P_RJT may 
occur for any Data frame. Each of these 
responses contributes to end-to-end and buffer- 
to-buffer flow controls. 


Class 2 buffers at the Sequence Recipient N_ Port 
are shared by multiple source N Ports which 
may be multiplexing. This Class 2 multiplexing 
requires the distribution of Class 2 Credit to 
each source N Port to be honored, to prevent 
BSY or RJT. Unless an adequate number of 
Class 2 buffers is available and Credit distrib- 
ution is honored, a BSY or RJT may occur in 
Class 2. 
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25.7 Integrated Class 2 flow control 


SI Front-end Back-end SR 
. N Port F Port F Port N Port 
Integrated buffer-to-buffer and end-to-end flow 
controls applicable to Class 2 is illustrated in EE BB. BB_ BB_ BBC 
r 3 frame from t e res j- Credit_ Credit_ Credit_ Credit_ Credit_ Credit_ 
figure 63 for a Data fra he Sequence In ae ane ae ie ea 


tiator N Port and its response from the 
Sequence Recipient N_Port. 


Class 2 Class 2 
25.7.1 Management Data frame Data frame 
— — we ise ome —_> =—T 
Hae 1 eco! bees Pinel as —> 
Integrated Class 2 flow control management is teas 
summarized in table 48. . eg ates fare 
R_RDY 
F_BSY/F_RJT P_BSY/P_RJT 
P_BSY/P_RJT ACK 
ACK «+ ---- 
Qe —- —- - ~- - 
St eS. —_—> 
R_RDY 
---f- —> 
R_RDY 


m = number of valid frames acknowledged collectively 


Figure 63. Integrated Class 2 flow control 


Table 48. Integrated Class 2 flow control management 


N_ Port 
Activity 


EE Credit CNT. | BB Credit CNT 
Port receives ACK_1 


Port transmits F_BSY, F_RJT, P_BSY, P_RUT, or 
ACK 


Note: NA - Not Applicable 
m - number of valid frames acknowledged collectively 


BB_Credit_CNT 


| > 
z 


= ! ' =ict+ 
+ Zzizi2a + 
+ zZizi2a 1 + 


> 
>|} 


> 
> 
z 
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= 
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Table 49. End-to-end flow control management 


EE Credit_CNT 


Pe Mhy (N_Port only) 


N Port transmits a Class 1 or Class 2 Data frame 
N_Port receives F_BSY, F_RJT, P_BSY, or P_RJT 
N_ Port receives ACK_1 
N_ Port receives ACK_N 


N Port receives a Data frame (Class 1, Class 2 or Class 3) 


> 


N_ Port transmits a Class 3 Data frame 
N_ Port transmits P_BSY or P_RJT | 
N_ Port trasnmits ACK 


Note: NA - Not Applicable 
m - number of valid frames acknowledged collectively 


>| > 


pg (ee a aes + 


Table 50. Buffer-to-buffer flow control management 


BB_Credit_CNT 
Activity (N_Port or 


Note: NA - Not Applicable 
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26 Segmentation and Reassembly 


26.1 Introduction 


Segmentation and Reassembly provides a func- 
tion to transfer blocks of data from a data source 
to a data target. The source data may consist of 
one or more blocks of data. Each block or sub- 
block of data is segmented, transferred, and 
recombined at the destination and may be scat- 
tered over an address space. 


Mechanisms 
FC-2 mechanisms to support this function are: 


1. Relative Offset 
2. Sequence 
3. Exchange 


Applicability 
All these mechanisms are applicable to all 
Classes. 


Offset 

The Relative Offset field in the Frame Header is 
used to indicate the relative displacement of first 
byte of Payload from a base address. The base 
address is specified by the ULP to FC-2. The 
base address is meaningful to the communi- 
cating ULPs and is not defined in this standard. 
The ULP’s base address forms the Initial Offset 
to FC-2. The Initial Offset may be applicable to 
a block or a sub-block or multiple blocks of data 
as specified by the sending ULP. 


26.2 ‘Application data mapping 


Mapping block(s) of application data to 
Sequence(s) at the sending end or Sequence(s) 
to block(s) of data at the receiving end by the 
ULPs is outside the scope of this standard but is 
performed within the N_ Ports. 


26.2.1 Mechanism usage 


FC-2 mechanisms available for mapping are 
described and listed in Table 51. 


1. A given block of data may be mapped by the 
sending end ULP for transfer by FC-2 as a 
single Sequence: 

— for N_Port to N_Port communication 
— with single Initial Offset for the block of 
data and 
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— with a transmitting order beginning from 
the start address to end address of the 
block of data. 


2. A given block of data may be split by the 


sending end ULP for transfer by FC-2 in mul- 

tiple Sequences: 

— for N Port to N Port or Node to Node 
communication 

— with single Initial Offset for the block of 
data with no natural scattering at the 
receiver or 

— with an Initial Offset for each Sequence 
with natural scattering at the receiver 
and 

— with a transmitting order beginning from 
the start address to end address of each 
sub-block of data. 


. Multiple blocks of data may be gathered by 


the sending end ULP for transfer by FC-2 ina 

single Sequence: 

— for N_ Port to N_ Port communication 

— with an Initial Offset for each block of 
data with natural scattering at the 
receiver or 

— with a_e single Initial Offset for the 
Sequence with no natural scattering at 
the receiver and 

— with a transmitting order beginning from 
the start address to end address of each 
block of data. 


. Multiple blocks of data may be gathered by = 


the sending end ULP for transfer by FC-2 in 

multiple Sequences: 

— for N Port to N Port or Node to Node 
communication 

— with an Initial Offset for each block of 
data with natural scattering at the 
receiver or 

— with a single Initial Offset for the 
Sequence with natural scattering at 
Sequence boundaries at the receiver or 

— with a single Initial Offset for the whole 
Exchange with no natural scattering at 
the receiver and 

— with a transmitting order beginning from 
the start address to end address of each 
block of data. 
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Table 51. FC-2 mechanisms mapping 


Commu- 
nicating 
entities 


Number 


Number 
of blocks 
of data 


Initial Offset coverage 


1 Initial Offset per 
block 


1 Initial Offset per 
block 
OR 


1 Initial Offset per 
Sequence 
OR 


1 Initial Offset per 
Exchange 


1 Initial Offset per 
block 


OR 


1 Initial Offset per 
Sequence 


1 Initial Offset per 
block 
OR 


1 Initial Offset per 
Sequence 
OR 


1 Initial Offset per 
Exchange 


Transmit 


Natural 
gather/scatter 
order at 

send/receive 


Start to 
end 
address 
of each 
block 


NA/NA 


Start to split/no scatter 


end 
address 
of each 

sub- 

block 


split/scatter 


split/no scatter 


Start to 
end scatter 


gather/no scatter 


gather/scatter 


address 
of each 
block 


Start to 
end 


address 
of each 
block 


gather/scatter 


gather/no scatter 


Note: 


M, N - integers 


NA - Not Applicable 


26.3 Segmentation 


A block or a sub-block of data to be transferred 
is segmented by FC-2 into multiple frames not to 
exceed the maximum size allowed as_ per 
service parameters interchanged (see 23.5 and 
23.6). FC-2 allows equal or varied size of 
payload in each frame within this maximum. 
FC-2 transmits each block or sub-block of data 
sequentially from the start address to the end 
address of the block or sub-block. FC-2 supports 
transmission of a block of data as a single 
Sequence or multiple Sequences. FC-2 supports 
transmission of multiple blocks of data as a 
single Sequence. 


During Segmentation, FC-2 


1. determines the Size of Payload for each 
frame, 

2. computes the Offset of the Payload from the 
initial Offset provided by the ULP; and 

3. emdeds the Payload in the Data field and the 
computed Offset value in the Offset field. 


26.3.1 Sequence Segmentation rules 


Segmentation rules applicable to each Sequence 
are specified: 


1. The sending end ULP is responsible to map 
multiple blocks or a single block or a sub- 
block of data to be transferred as a 
Sequence. 

2. The ULP shall specify the Payload for the 
last frame in its entirety before FC-2 starts 
transfer of that frame. 
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. Unless the ULP specifies the Initial Offset, it 


is assumed to be FFFFFFFF hex. 


. The Sequence Initiator is responsible for 


Segmentation management of the Sequence. 


. The Sequence Initiator subdivides the block 


or sub-block of data into Payloads of equal 


10. 


11. 


12. 


13. 
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or varied sizes. 


. The Sequence Initiator shall compute Offset 


for Payload with reference to Initial Offset 
and embed it in each frame. The Offset shall 
indicate the relative address of the first byte 
of Payload in the Data field. 


. In Class 1, the maximum size of these 


frames is governed by service parameters 

interchanged between the communicating 

N_ Ports. | 

A. Class 1 connect request frame is 
however governed by service parame- 
ters of N Ports as well as Fabric. (see 
28.4.3). 


. In Class 2 and Class 3, the maximum size of 


these frames is governed by service param- 
eters interchanged between the communi- 
cating N_Ports as well as Fabric. 


. The Sequence Initiator assigns a unique 


SEQ ID which is common to all frames 
within the Sequence. 

The Sequence Initiator always assigns 
SEQ CNT sequentially by the order in which 
the frames are transmitted, beginning at the 
start address of the block or sub-block to its 
end address. 

The Sequence Initiator uses Offset in each 
frame and with all Classes. 

The block or sub-block of data is treated as 
a stream of bytes in FC-2. 

The Sequence Initiator shall follow the Initial 
Offset coverage requested by the ULP. 


26.3.2 Exchange Segmentation rules 


Segmentation rules applicable to a multiple 
Sequences are specified: 


1. An Exchange may be used to transfer over 
one or more N Ports. 

A. Blocks or sub-blocks of data transferred 
(within an Exchange) over an N Port 
shall be non-concurrent. 

B. Blocks or sub-blocks of data transferred 
(within an Exchange) over multiple 
N Ports may be concurrent. 

C. Multiple Exchanges shall be used to 
transfer multiple concurrent blocks of 
data over a single N_ Port. 

2. The Originator or Responder shall perform 
non-concurrent transfer of multiple blocks of 
data over an N Port as multiple non- 
concurrent Sequences within an Exchange. 

3. The Originator or Responder shall perform 
multiple concurrent Sequences either as 
multiple Exchanges over an N_ Port or one or 
more Exchanges over Multiple N_ Ports. 

4. Frames within the Exchange may be trans- 
ferred through a single N_ Port or over a mul- 
tiple N_ Ports. 


A. The Originator or Responder shall set 
the Exchange Reassembly bit (F_CTL Bit 
2) to zero, indicating blocks or sub- 
blocks of data are transferred as an 
Exchange on a single N_ Port. 


B. The Originator or Responder shall set 
the Exchange Reassembly bit (F_CTL Bit 
2) to one, indicating blocks or sub-blocks 
of data are transferred as an Exchange 
on multiple N_ Ports. 


5. All Sequence Segmentation rules are appli- 
cable to individual Sequences within an 
Exchange. 


26.4 Reassembly 


The Recipient N Port packs Payload of each 
frame at a displacement, indicated by the Offset 
specified in the Frame_Header. 


26.4.1 Sequence Reassembly rules 


Reassembly rules applicable to blocks or sub- 
blocks of data received as a Sequence are spec- 
ified: 


1. 


2. 


3. 


The Sequence Recipient is responsible for 
Reassembly. 

The Recipient shall reassemble the blocks or 
sub-blocks of data on the S_ID || OX_ID or 
RX_ID |JSEQ_ID basis. 

The first byte of each frame’s Payload is 
received at the address indicated by Offset 
specified in the Frame_Header. 
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26.4.2 Exchange Reassembly rules 


All Sequence Reassembly rules are applicable 
to Exchange Reassembly. Additional rules are: 


1. If the Exchange Reassembly bit (F_CTL Bit 2) 


is set to zero, the Originator or Responder 
shall receive blocks or sub-blocks of data on 
a single N_ Port. 


. If the Exchange Reassembly bit (F_CTL Bit 2) 


is set to one, the Originator or Responder 
shall receive blocks or sub-blocks of data on 
multiple N_ Ports. 
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27 Primitive Sequence Protocols 


27.1 Introduction 


The interchange of frames is basically asynchro- 
nous in nature. The Data protocols defined in 
this standard allow multiple frames in flight in 
each direction at the same time. When serious 
link errors are detected or state changes occur 
within an N_ Port, Primitive Sequence Protocols 
provide a synchronous mechanism to recover 
from those errors or state changes. 


27.2 Primitive Sequences 


Table 52. provides a summary of the Primitive 
Sequences defined, their meaning to the trans- 
mitter, and the corresponding response when 
received. A more complete description of Primi- 
tive Sequences is found in 16.4. 


Table 52. Primitive Sequence Summary 


| Name| Meaning to Transmitter | Resp | 


Not-Operational OLS 
- Link Failure 


- Internal failure in Port 
- Not operational state 


Offline Sequence 

- Transmitter may 
power-down, 
perform diagnostics, or 
perform initialization. 

- Receiver shall ignore 

Link errors or Link Failure. 


Link Reset 

- Remove Class 1 
Connection, 

- Reset F_Port, or 

- OLS recognized 


LRR Link Reset Response 
- Link Reset recognized 


| idles | Operational Link 
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27.3 Link Initialization 


Link initialization is required after a Port has 
been powered-on or has been internally reset. 
The Ports involved may be an N Port and an 
F Port, or two N_Ports. 


The following series of events defines the Link 
Initialization Protocol. 


1. Transmit OLS. 
2. When LR is recognized, transmit LRR. 
3. When Idles are recognized, transmit Idles. 


27.4 Online to Offline 


An N_ Port performs the Online to Offline pro- 
tocol to enter the Offline State. The Offline State 
is entered prior to power-down or performing 
diagnostics. To exit the Offline State, an N_ Port 
performs the Link Initialization Protocol. 


The following series of events defines the Online 
to Offline Protocol. 


1. Transmit OLS 
2. When LR is recognized, or the timeout 
period has expired, the Port may: 
— perform diagnostics, 
— reinitialize, or 
— power-down 


27.5 Link Failure 


The Link Failure protocol is performed after a 
Port has either detected a loss of synchroniza- 
tion for a period of time greater than the timeout 
period, or has detected loss of signal, while not 
in the Offline State. 


The Link Failure protocol is also performed after 
a Link Recovery timeout error is detected (see 
27.6). 


The following series of events defines the Link 
Failure Protocol. 


1. Transmit NOS. 
2. When OLS is recognized, transmit LR. 
3. When LRR is recognized, transmit Idles. 


27.6 Link Recovery 


The Link Recovery protocol is performed fol- 


lowing a Link timeout. If a Port performs step 1, 


2, or 3 without receiving the appropriate 
response within the timeout period, a _ Link 
Failure is detected and the Link Failure protocol 
is performed. 
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The following series of events defines the Link 
Recovery Protocol. 


1. Transmit LR. 

2. If LR is recognized, transmit LRR. 

3. If LRR is recognized, transmit Idles. 
4. If Idles are recognized, transmit Idles. 


At the conclusion of Link Recovery both Ports 
shall be transmitting and receiving Idles. 
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28 Connection Management 


The procedures for establishing and removing 
Class 1 Dedicated Connections are specified in 
this clause. See Annex P for application exam- 
ples for removing a connection as well as an 
N Port State Diagram of the Connect and Dis- 
connect Process. | 


28.1 Introduction 

Class 1 Service is based on establishing a Dedi- 
cated Connection between a source N_ Port and 
a destination N_ Port. The Dedicated Connection 
guarantees that the full bandwidth of the Link is 
available to each N_ Port. 


Establishing a Connection: 


In order to establish a Class 1 Dedicated Con- 
nection, the source N Port transmits a Data 
frame to a destination N Port with an SOFc1 
delimiter. The Data field size of the connect- 
request frame is limited by the maximum 
Receive Data_Field size specified by the Class 1 
service Parameters of the Fabric or by the 
maximum Receive Data Field size specified by 
the destination N_ Port, whichever is smaller. 


The N_ Port receives an R_RDY Primitive Signal 
to indicate that the connect-request frame was 
received successfully and a buffer in the F_Port 
or N_ Port is available. When the N_ Port trans- 
mitting the connect-request receives an ACK 
response frame (ACK_1 or ACK_N) with an 
SOFn1 with the appropriate S_ID and D_ID fields 
of the connect-request frame, a Dedicated Con- 
nection is established. 


When a Dedicated Connection is established: 


1. the N_Port initiating the connection is known 
as the Connection Initiator and the N_Port 
responding to the connect-request is known 
as the Connection Recipient. 

2. the Connection Initiator continues the initial 
Sequence, and 

3. each N Port may initiate new Sequences 
with an SOFi1 delimiter. 
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Removing a Connection: 


Removing a Dedicated Connection is accom- 
plished by either N Port transmitting a frame ter- 
minated by an EOFdt. Removing a Dedicated 
Connection shall be negotiated between the two 
N Ports involved. Negotiation is required in 
order to avoid breaking the Dedicated Con- 
nection while frames are still flowing between 
the N_Ports. 


The Fabric terminates a Dedicated Connection 
after an EOFdt or EOFati passes through the 
F Port in either direction. Any frames flowing in 
either direction at the time the Connection is 
removed may be corrupted. 


End Connection (E_C) is the control Bit in F_CTL 
which is used to perform the negotiation. 


28.2 Applicability  - 


Connection management applies to Class 1 
Service. An N Port supporting Class 1 Service 
may also support Class 2 and Class 3. 
Depending on the options supported by the 
Fabric, multiple class support by an N_ Port may 
be complex. Because Class 1 involves Dedi- 
cated Connections, managing Class 1 usually 
overrides Class 2 or 3 management. The 
Standard specifies the allowable responses on a 
Class by Class basis. 


28.3 Topology Models 


An N Port may be attached directly to another 
N_ Port through a point to point connection or to 
a Fabric. The topology may be determined using 
the explicit Login procedure. 


28.3.1 Fabric model 


The N_ Port model is based on an F_Port which 
acts as the control point for establishing and 
removing Class 1 connections on behalf of the 
attached N Port. The N Port relies on specific 
behavioral characteristics in order to base its 

operation. | 


The following terminology is used in the dis- 
cussion of Connection management. N_ Port (A) 
refers to the N Port originating the connect- 
request and N Port (B) refers to the destination 
N_ Port of the connect-request. The side of the 
F Port directly attached to the N Port side is 
termed its “Link” side, whereas the side of the 
F Port attached internally to the Fabric is termed 
its “internal” side. 


The following F_Port characteristics are required 
behavior: 


1. When an F_Port is in an inactive state or 
“not connnected”, it may receive a connect- 
request and begin processing that request. 
The process of acting on that request is 
termed accepting the connect-request. 

2. After an F_Port has accepted a _ connect- 
request from the Link, it reserves Fabric 
resources as it attempts to establish the 
requested Dedicated Connection. 

— the F_Port is Busy to other connect- 
requests from its internal side as desti- 
nation N_ Port. 

— the F_Port returns an F_BSY with EOFat 
to the Link if a busy condition is encount- 
ered. (lf a Fabric supports queued 
connect-requests, the period of time 
before issuing an F_BSY may be 
extended.) 

— the F Port returns an F_RJT with EOFat 
to the Link if a reject condition ts satis- 
fied. 

3. After an F Port has accepted a_ connect- 
request from the internal side: 

— it passes the connect-request to the Link 
as the destination N_ Port. 

— it monitors its Link side for a proper con- 
firmation response frame expected in 


response to the delivered connect- 
request. 
— it discards connect-request frames 


(SOFc1) received from its Link side. (If 
the Fabric supports queued connect- 
requests, the connect-request received 
from its Link side shall be queued for a 
establishing a Dedicated Connection at a 
later time.) 

4. lf an F Port encounters a collision case 
wherein connect-requests from both the 
internal side and the Link side arrive simul- 
taneously, the F_Port accepts the connect- 
request from the internal side and proceeds 
as in step 3 above. 
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28.3.2 Point to Point Model 


A point to point topology is indicated during the 
Login procedure. Two N Ports arranged in a 
point to point connection may choose to: 


4. establish one Dedicated Connection for the 
duration of an operating period, or 


2. establish and remove Dedicated Connections 
dynamically, as the need to communicate 
arises. 


28.4 Establishing a Connection 


A Dedicated Connection is established with an 
N Port as the source of a connect-request (Con- 
nection Initiator) or as the destination N Port 
(Connection Recipient) of a connect-request from 
another Class 1 N_ Port. 


28.4.1 Connection Initiator 


When FC-2 receives a request from an upper 
level to initiate a Class 1 Sequence when a Dedi- 
cated Connection does not exist, the N Port 
must also establish a Class 1 Connection with 
the destination N_ Port as part of the Sequence 
initiation. 


The N Port (A) initiates the connect-request 
using a Data (Device _Data or Link_Data) frame 
with an SOFc1 delimiter. The Data Field size is 
limited to the smaller of: 


— the maximum Receive Data Field size 
specified by the Fabric, if present, or 

— the maximum Receive Data _Field size 
specified by the destination N_ Port. 


After the N_ Port transmits the connect-request 
frame, the N Port shall not transmit another 
frame for this Sequence until a response frame 
has been received. The N Port receives an 
R_RDY Primitive in response to the connect- 
request to indicate successful delivery to the 
F Port or N_Port and that a buffer is available for 
a connectionless frame. If an N_Port is not oper- 
ating in Intermix mode, the N Port shall not 
transmit Class 2 or 3 frames until the pending 
Dedicated Connection is removed. A Dedicated 
Connection is not established until a proper ACK 
frame is received from the destination N Port. A 
proper ACK frame is defined in 28.4.3.1 item 
number 4. 
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Table 53 defines Event 1 as the connect-request 
and events 2 through 8 define the possible 
responses. 


Table 53. a to connect-request (SOFc1) 


P_BSY 


=| 


N_Port Action 
-Transmit connect-request 
-Wait for confirmation frame 


Connection failed, Busy in Fabric 


EOFdt Connection failed, Busy in N_Port 
Connection failed, Fabric Reject 
Connection failed, Port Reject 


-Dedicated Connection established 


-Continue transmitting Sequence 


A. PTP:if A > Xin value, 


-discard X’s frame and wait for response. 


B. Fabric and PTP: ifA < X: 


-Requeue request assoc with event 1 (SOFi1) 
-Respond with SOFn1 on ACK_1 or ACK_N. 
-Dedicated Connection established with X. 


-Timeout, no response frame. 


-Perform Link Recovery Protocol. (see 27.6) 


1. N_Port (A) is the Connection Initi- 
ator and N Port (B) is the Con- 


Event 1 A connect-request is transmitted by nection Recipient 
N Port (A) with an SOFet1 delimiter ere 
with a destination of N_ Port (B). 2. N_Port (A) may continue transmit- 
Event2 An F_BSY indicates that the Fabric is UAE SE AE SN Ce NIBIEe 
unable to access the _ destination 3. N Port (A) may _ initiate other 
N Port due to a _ busy condition Sequences with the same desti- 
internal to the Fabric. Try again later. nation N Port (B) up to the 
Event 3 A P _BSY indicates that the destina- maxinany number an isle 
ee et ae ; defined by the Service Parame- 
tion N Port link facility is temporarily 
ig i ters obtained from (B) during 
occupied with other activity § and 
Login. 
unable to accept the connect-request. 
Try again later. 4. The connected N Port (B) may 
Event 4 An F_ RJT indicates that the Fabric is uullate Sequences Heing sOrute 
- start each Sequence. The 
unable to establish the Dedicated ; ; 
; ; number of active Sequences is 
Connection. The reason code speci- aoe 
fiesta cauee limited by the Service Parameters 
provided by N Port (A) during 
Event5 A P_RJT indicates that the destination Login. 
Neon = ene restau GOCE. Event 7 In the case of a point to point (PTP) 
icated Connection. The reason code 
ceaciies ane GauKe topology, if (A) is greater than (>) (X) 
P | in absolute value, then N_Port (A) dis- 
Event 6 A Dedicated Connection has been cards the connect-request and waits 
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established. N Port (A) is Connected 
to N_Port (B). 


for a response (N_Port (X) requeues 
request with SOFi1). 


In the case of a PTP topology where 
(A) < (X), or a Fabric is present, 
N Port (A) terminates its own pre- 
vious connect-request with the intent 
of retransmission at a later time (i.e. 
requeues Event 1 with SOFi1 or SOFc1 
as appropriate). N_ Port (A) responds 
as the destination of the connect- 
request with an appropriate ACK 
frame and becomes the Connection 
Recipient. N Port (X) is the Con- 
nection Initiator. 


Event 8 If a frame response is not received 
within the timeout period, a_ Link 
timeout is detected and the Link 
Recovery Protocol is performed (see 
27.6). 

See 28.4.3, “Connect-Request Rules” for the 


rules which a source N Port of a _ connect- 


request shall follow. 


28.4.2 Destination of Connect-Request 


When N _ Port (B) is not connected, but is avail- 
able, and it receives a connect-request as the 
destination N_ Port, N_Port (B) transmits the 
appropriate ACK frame (ACK_1 or ACK_N) to 
N_ Port (A) which is requesting the connection. 
After the response frame has been transmitted 
with SOFn1, a Dedicated Connection is estab- 
lished with N_ Port (A) as the Connection Initiator 
and N Port (B) as the Connection Recipient. 
After a Connection has been established, N_Port 
(B) may initiate Sequences with the N_ Port (A) 
using an SOFi1 delimiter. 


If N_ Port (B) is not connected, but is busy, and it 
receives a connect-request as the destination 
N_ Port from N_ Port {A), it responds with P_BSY 
with an EOFadt delimiter. 


See 28.4.3, “Connect-Request Rules” for the 
rules which a destination N Port of a connect- 
request shall follow. 


28.4.3 Connect-Request Rules 


The following sections specify the rules gov- 
erning the behavior of the source and destina- 
tion of the connect-request. 
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28.4.3.1 Source of Connect-Request 


The following rules specify the connect-request 
procedure as the source (A) of the connect- 
request: 


1. An N Port (A) initiates a connect-request 
using a Data (Device Data or Link Data) 
frame with an SOFc1 delimiter directed to 
destination N_ Port (B). The connect-request 
frame is formed as follows: 

— an SOFc1 delimiter 
— a Data (Device data or Link_Data) frame 
— anS_ID of (A) and a D_ID of (B) 

2. The Data Field of the connect-request is 
limited to the smaller of. 

— the maximum Receive Data Field size 
specified by the Fabric, if present, or 

— the maximum Receive _Data_Field size 
specified by the destination N_ Port. 

3. After N Port (A) transmits the connect- 
request frame, N Port (A) shall wait for a 
response frame before transmitting another 
frame for this Sequence. 

4. A Dedicated Connection is established when 
the connect-request frame has been 
responded to by a proper response frame. A 
proper response frame consists of: 

— a ACK_1 or ACK_N frame with 
— an SOFni delimiter, and 
— anS_ID of (B), and a D_ID of (A) 

5. An alternate response frame is also possible 

from the destination N_ Port: 

— aP_BSY or P_RuT frame with 

— an SOFn1 delimiter, 

— anS_ID of (B), and a D_ID of (A), and 
— an EOFat ending delimiter. 

6. An alternate response frame is also possible 

from the Fabric: 

— an F_BSY or F_RuT frame with 

— an SOFn1 delimiter, 

— an S$_ID of (FFFFFE), and a D_ID of (A), 
and 

— an EOFdt ending delimiter. 

7. After a Dedicated Connection is established, 
N Port (A) is the Connection Initiator and 
N_ Port (B) is the Connection Recipient. 

8. The Connection Initiator, N Port (A), may 
continue transmitting its initial Sequence and 
initiate other Sequences with SOFi1 up to 
N Port (B)’s ability to support Concurrent 
Sequences. 
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28.4.3.2 Destination of Connect-Request 


The following rules specify the connect-request 
procedure as the destination (B) of the connect- 
request: 


1. If a Data frame started by SOFc1 is received 
when N_ Port (B) is not connected and N_Port 
(B) is busy, N_ Port (B) responds with P_BSY 
with an EOFdt delimiter as specified in 
28.4.3.1 item number 5. 

2. If a Data frame started by SOFc1 is received 
when N_Port (B) is not connected and not 
busy, N_Port (B) responds with the proper 
response frame. A proper response frame is 
defined in 28.4.3.1 item number 4. 


A Dedicated Connection is established with 
N_ Port (A). N_ Port (B) is the Connection 
Recipient and N Port (A) as the Connection 
Initiator. 

3. With a Fabric present, if N Port (B) receives 
a connect-request frame from N Port (X) 
after a connect-request has been trans- 
mitted, N Port (B) requeues its own request 
for transmission at a later time and responds 
with a proper response frame to N_Port (X). 


A Dedicated Connection is established with 
N_ Port (X) with N Port (B) as Connection 
Recipient. 

4. Without a_ Fabric 
responds as follows: 
A. if A > B, in value, 

— N Port (B) discards connect-request 
from (A), and 
— waits for a proper response frame. 
B. if A < B, in value, 
— N Port (B) requeues its own request 
for transmission at a later time, 


present, N Port (B) 


— responds to (A) with a_ proper 
response frame, 
— a Dedicated Connection is estab- 


lished with N_Port (A) with N_ Port (B) 
as Connection Recipient, and 

— N Port (B) may initiate its connect- 
request Sequence using SOFi1. 

5. After a Dedicated Connection is established, 
N_ Port (B) may begin initiating Sequences 
with SOFi1 up to the destination N_ Port’s 
ability to support Concurrent Sequences. 
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28.5 Connected 


When an N Port is in a Dedicated Connection, it 
may receive Sequences as the Sequence Recip- 
ient as well as initiate Sequences as_ the 
Sequence Initiator. 


28.6 Removing a Connection 


28.6.1 Connection_Resource control bit 


This document does not specify the method to 
be employed in determining when to end a con- 
nection. However, a Connection Resource bit in 
F CTL (see 18.5) is defined to provide informa- 
tion between N_Ports. 


28.6.2 End_Connection control bit 


An E_C control Bit in F_CTL is used during the 
remove connection procedure. By monitoring 
both transmission of the E_C control Bit as well 
as reception of the E_C control Bit, each N_ Port 
is able to determine the appropriate circum- 
stances to transmit an EOFadt in order to remove 
the connection. 


E Cis transmitted as zero in a frame to indicate: 


1. This N_ Port wishes to maintain the existing 
Dedicated Connection. 

2. This N Port may transmit another Sequence 
within this Connection. 

3. This N Port may wait for a reply Sequence 
within this Connection. 


E Cis transmitted as one on a frame to indicate: 


1. This N Port is ready to remove the existing 
Dedicated Connection. 

2. This N Port has completed all active 
Sequences and agrees not to initiate another 
Sequence. 

3. This N Port is requesting the destination 
N Port to complete active Sequences in 
progress and not initiate any new 
Sequences. 


E_C may be transmitted set to one in two cases: 


1. on an ACK response frame to indicate that 
this N_Port requests the-receiving N_ Port to 
complete active Sequences and not initiate 
any new Sequences, or 


Link Recovery 153 

Link Recovery Protocol 153, 159 

Link timeout 159 

Link_Continue 86 

Link_Response 87 

LOG! 95 

Login 95, 112 

Login (Explicit) 112 

Login (Implicit) 112 

LOGO 95 

Logout 95 

loopback 186 

Loopback mode 63, 218, 220, 223 

loss budget 
multimode 504 42, 189 
multimode 62.54 41, 189 
single mode 40, 189 


- 


media 12 

modal noise 29 

model 9 
Duplex 225 
hduplex 225 
Physical 12 
simplex 226 


n 


No Operation 97, 104 

Node 12 

Node Identifier 13 

nominal distance, multimode 190 
nominal distance, single mode 189 
NOP _ 97, 104 

N Port 12 

N Port Login 115 


Oo 


open fiber control system (OFC) 30 
time periods 33, 209 

Open Sequence 133 

optical return loss 40 

Ordered Set 51 
Non-Repeating Ordered Set 216, 217, 218 
Repeating Ordered Set 216, 217, 218 
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Originator 77, 130 
out of order 121 
OX_ID (Originator Exchange _ ID) 77, 130 


G 


P-P 14 

Parameter 87 

Physical model 12 

point-to-point topology 14, 155 

Port Identifier 13 

power penalty 29, 189 

Primitive Sequence 52 

Primitive Signal 52 

protocol 93, 112 

pulse shape 28 
measurement 174 

P ACC 106 

P BSY 91, 106, 107, 109 

P RDY 106, 107, 109 

P RJT 88, 106, 107, 109 
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RCS 98 

RDY 86 

Read Connection Status 98 

Read Exchange Status 99 

Read Sequence Status 100 

Reassembly 151 

receive Data Field size 122 

receiver characteristics 29 

receiver initialization 24 

receiver overload 29 

receiver states 24, 54, 59, 212 
Loss-Of-Signal-Failure 54, 58, 212 
Loss-Of-Synchronization 54, 55, 63, 212, 224 
Loss-Of-Synchronization-Failure 54, 58, 212 
Offline 54, 58, 212, 220, 222 
Reset 54, 59, 213, 222 
Synchronization-Acquired 54, 63, 212, 220, 

224 

reflection 40, 189 

reflection noise 29 
measurement 177 

Relative Offset 78, 102, 134, 148 

Remove Connection 98, 158 

Removing Connection 154 

RES 99 
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Responder 130, 131 

revise Credit 101, 127 

RJT 88, 102 

RMC_ 98 

RSS 100 

Running Disparity 47, 53 

RX_ID (Responder Exchange_ID) 78, 131 
R_RDY 86 
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safety redundancy 33 
Segmentation 149 
self-pulsating laser 29 
self-pulsation frequency 29 
sequence 96, 128 
Sequence Count (SEQ CNT) 77, 128 
Sequence Initiative 129 
Sequence Initiator 76, 132 
Sequence Recipient 76, 133 
Sequence timeout 134, 159 
SEQ CNT 134, 137 
SEQ ID 134 | 
SEQ ID (Sequence ldentifier) 76 
Service Options 119 
Service Parameters 112, 118 
short wavelength laser (SW) 29 
SIBA 14 
signal detect 24, 186 
signal interface options 25 
simplex 226 
Single InBand Address topology 14 
SOF (Start_of_Frame) 65, 68 
SOFc1 (connect) 68, 106 
SOFf¢f (Fabric) 69 
SOFi1 (initiate) 68, 106 
SOFi2 (initiate) 68, 107 
SOFi3 (initiate) 69, 109 
SOFn1 (normal) 69, 106 
SOFn2 (normal) 69, 107 
SOFn3 (normal) 69, 109 
SOFc1 (connect) 155 
spectral width 34 
splice 43 
Synchronization 54 
bit synchronization 55 
loss of Synchronization 55 
Transmission-Word synchronization 55 


test methods 174 
active input interface 175 
distortion and jitter 176 
DJ 176 
extinction ratio 175 
eye opening 176 
jitter 175 
mask of the eye 174 
optical power 174 
optical spectrum 174 
optical waveform 174 
pulse parameters 175 
RIN 177 
rise/fall time 175 
RJ 177 
test patterns 
active input interface 175 
DJ 176 
LED pulse parameters 175 
optical power measurement 174 
RJ 177 
Topology 
point-to-point 14 
Single InBand Address 14 
Transmission Character 45 
Data Character 45, 48 
generation from Valid Data Byte or Special 
Code 47 
Special Character 45, 51, 55 
valid and invalid 47 
validity checking 47 
Transmission Code 45 
bit notation 45 
naming convention 46 
transmission order 46 
Transmission Word 55 
alignment 53, 55, 215 
invalid 56 
transmitter states 23, 60, 61, 213 
Failure 60, 61, 213 
Not-Enabled 60, 61, 63, 213, 218, 223, 224 
Working 60, 63, 214, 218, 223, 224 
transport 12 
TYPE 73 


2. on the last Data frame of the last active 
Sequence for this Connection to indicate that 
this N Port requests the receiving N_ Port to 
transmit EOFat on the ACK response frame if 
the receiving N Port has completed all 
active Sequences. 


28.6.3 EOFdt transmission 


EOFat is transmitted by either the Connection Ini- 
tiator or the Connection Recipient on an ACK 
frame corresponding to the last Data frame of a 
Sequence with the E_C control Bit set to one if 
the N_ Port receiving the Data frame has com- 
pleted its last active Sequence of the existing 
Connection. 


If both N Ports have transmitted their last Data 
frame of a Sequence with E_C set to one but 
have not received the ACK frame to complete 
the Sequence, the Connection Initiator delays 
transmitting ACK until it has received the ACK 
for its last Sequence. After the Connection Initi- 
ator has completed its last Sequence, it trans- 
mits the final ACK to the Connection Recipient 
with the EOFdt delimiter to remove the Con- 
nection. 


28.7 Remove Connection Rules 


1. An active Sequence is complete when the 
corresponding ACK response has_ been 
transmitted by the Sequence Recipient from 
the Recipient’s perspective and has been 
received by the Sequence Initiator from the 
Initiator’s perspective in response to the last 
Data frame of the Sequence. 

2. An N_Port transmits the E_C F_CTL Bit set to 
one to indicate: 

— itis ready to end the Connection, 

— it shall not initiate any new Sequences, 
and 

— it requests the other N_ Port to complete 
its active Sequences and not initiate any 
new Sequences. 

3. If an N_ Port has transmitted the E_C F_CTL 
Bit set to one and it receives a Data frame 
initiating a new Sequence, it responds as 
though the Sequence had been initiated 
before the E_C Bit had been transmitted as 
one. 

4. lf either the Connection Initiator or Con- 
nection Recipient have completed its last 
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active Sequence of the existing Connection 

and it receives a Data frame with E _C set to 

one, it transmits the corresponding ACK with 
an EOFat delimiter. 

5. If an N Port encounters a collision case 
wherein a Data frame has been transmitted 
with E_C set to one and a Data frame is 
received with EC set to one _ before 
receiving its ACK, 

— the Connection Recipient responds with 
an ACK with an EOFn1_ delimiter, 
whereas 

— the Connection Initiator withholds trans- 
mitting ACK until after its Sequence is 
complete. 

— the Connection Initiator transmits the 
ACK with the EOFat delimiter. 


28.8 Connection Recovery 


In case of link errors, the state of the existing 
Dedicated Connection may not be known with 
certainty. The Dedicated Connection is removed 
and the two Ports are brought to a known state 
using the Link Recovery Protocol (see 27.6). 
Errors within a specific Sequence are processed 
according to the rules for handling Sequence 
errors. 


28.8.1 Link timeout 


When the last active Sequence during a Class 1 
Dedicated Connection has detected a Sequence 
timeout, a Link Timeout is detected. The Link 
Recovery Protocol is performed as described in 
27.6. 


28.8.2 Corrupted connect-request 


If an N Port is not engaged in a Class 1 Dedi- 
cated Connection, and it receives a frame 
started by SOFc1 and the frame is detected as 
invalid, the N_Port discards the frame and per- 
forms the Link Recovery Protocol. 
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29 Error detection/recovery 


within a Sequence is tracked on the basis of 
Exchange ID, Sequence ID, and a sequence 


29.1. Introduction | 
Link integrity and Sequence integrity are the two | count within the Sequence. Each frame is veri- 
fundamental levels of error detection in FCS. | fied for validity during reception. Sequence 
Link integrity focuses on the inherent quality of | retransmission is used to recover from any 
the received transmission signal. When the | frame errors within the Sequence. 

integrity of the link is in question, a hierarchy of 
Primitive Sequences are used to reestablish link Credit loss is an indirect result of frame loss or 
integrity. When Primitive Sequence protocols errors. Credit loss is discussed in regard to 


| 

| 
are performed, additional data recovery on a_ | methods available to reclaim apparent lost 
Sequence basis may be required. | Credit resulting from other errors. See clause 
| 
| 
| 
| 


25 for a more complete discussion on flow 
control, buffer-to-buffer Credit, and end-to-end 
Credit. Table 54 summarizes the discussion on 
link integrity. 


A Sequence within an Exchange provides the 
basis for ensuring the integrity of the block of 
data transmitted and received. Each frame 


LINK ERROR RECOVERY 
Recovery Action Effects on Sequences 
Link Failure Protocol possible - Sequence timeout (Class 2), 
certain - Terminate Sequence (Class1) 
Link Failure Protocol possible - Sequence timeout (Class 2), 
certain - Terminate Sequence (Class1) 
Link Failure Protocol possible - Sequence timeout (Class 2), 
certain - Terminate Sequence (Class1) 
Link Recovery Protocol possible - Sequence timeout (Class 2), 
certain - Terminate Sequence (Class1) 
Code violation during Idles | Update LESB No effect on frames 


| Recovery from Link Failure is accomplished by 
| performing the Link Failure Protocol (see 27.5). 


29.2 Link error detection 


| 29.2.2 Link timeout 
Link errors are detected at three levels. 

| The second level of errors is logically detected 
29.2.1 Link failure | at the frame level with Link timeout detection. 


In Class 1, a Link Timeout error is detected 
during a Dedicated Connection if Sequence time- 
outs have been detected for all active 
sequences. 


The first level of link error detection is at the 
receiver. Link failure is detected under the fol- 
lowing conditions: 


— Loss of Signal, 

— Loss of Synchronization > timeout period 
(see 11.1 and -- Heading “LOSYN’ unknown 
=), 

— Link Recovery timeout (see 27.6.) 

— Reception of the Not Operational Primitive 
Sequence (see 16.4.2). 


In Class 1 (SOFc1), 2, or 3, a Link Timeout error 
is detected if one or more R_RDY Primitive 
Signals is not received within the timeout period 
after the buffer-to-buffer Credit_CNT has reached 
zero. 
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Recovery from link timeout is accomplished by 
performing the Link Recovery Protocol (see 
27.6). 


29.2.3 Code violations 


Code violations are link errors which result from 
an invalid transmission code point or disparity 
error. If a code violation occurs during Idles, it 
is recorded in the Link Error Status Block. If a 
code violation occurs during frame reception 
(see 29.10), the frame is discarded or processed 
based on the error policy being used. 


29.3 Link error recovery 


The Link recovery hierarchy is shown in figure 
64. 


The recovery protocols are nested and organ- 
ized from the most serious to least serious link 
action. | 


— link failure 
— link initialization 
— link recovery (reset) 


Primitive Sequence Protocols provide two basic 
functions. The first function is to notify the other 
end of the link that a specific type of link error 
has occurred. The second function is to reset 
the link to a known state at both ends. 


29.3.1 Link initialization and shutdown 


Link initialization is accomplished by performing 
the Link Initialization Protocol. When this pro- 
tocol is complete, the Port is synchronized, 
transmitting and receiving Idles. See 27.3. 


Shutdown prior to power-off is accomplished by 
the Online to Offline Protocol. This protocol pro- 
vides an attached Port with a graceful indication 
prior to loss of signal. This avoids logging an 
error event for a normal system function. 
27.4. 
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Figure 64. Link recovery hierarchy 


29.4 Link recovery - secondary 
effects 


If the recovery action from an error involving link 
integrity requires transmission of a Primitive 
sequence, Sequences within an Exchange may 
be adversely affected based on Class of Service. 


Class 1 

During a Class 1 Dedicated Connection, trans- 
mission or reception of Primitive Sequences 
removes the connection. While an N Port is 
transmitting a Primitive Sequence, it shall 
discard any Class 1 frames received. At the 
conclusion of the Primitive Sequence protocol, 
the end-to-end Credit and buffer-to-buffer Credit 


are reset to their original Login values in both 
N_ Ports and the F_Port’s involved. 


All frame Sequences that were active are termi- 
nated abnormally. Selective recovery on a 
Sequence by Sequence basis is required of the 
Sequence Initiator. When Sequences are abnor- 
mally terminated, the current status of each 
Sequence is posted in the corresponding 
Exchange Status Block and the Sequence Status 
Blocks are reset and released. Link resources 
associated with the active Sequences’ are 
released. If the Sequence Initiative is in doubt, 
the previous Initiator N_Port shall interrogate the 
other N_ Port’s Exchange Status Block to deter- 
mine which N Port has the Sequence Initiative 
(see 29.7.1). 


Class 2 

When Primitive Sequences are transmitted or 
received, the F_ Port shall discard any Class 2 
frames held in its buffers. After the Primitive 
Sequence protocol is completed, the buffer-to- 
buffer Credit is reset in an N_ Port and an F_Port. 
Both the N_Port and F_Port may begin transmit- 
ting frames. 


Active Sequences within an Exchange are not 
necessarily affected. Therefore, normal proc- 
essing continues and_ selective Sequence 
recovery is performed as required. 


Class 3 

When Primitive Sequences are transmitted or 
received, the F_Port shall discard any Class 3 
frames held in its buffers. After the Primitive 
Sequence protocol is completed, the buffer-to- 
buffer Credit is reset in an N_Port and an F_Port. 
Both the N_Port and F_Port may begin transmit- 
ting frames. 


29.5 Sequence integrity 
Applicability 


Since Class 3 does not use Link_Control frames, 
Sequence integrity is verified at the Sequence 
Recipient on a Sequence by Sequence basis. In 
Class 3, only the Recipient is aware of an out of 
order condition and communication of that infor- 
mation to the Initiator is the responsibility of 
FC-4. 
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The remaining discussion concentrates on Class 
1 and 2. Items applicable to Class 3 shall be 
specified explicitly. 


29.5.1 Exchange processing 


When an Exchange is originated, the Originator 
shall specify the required error policy of either 
discard or process using the Abort Sequence 
Condition bits in F_CTL. Process policy allows 
the receiving N Port to process frame content 
regardless of detected error conditions. Process 
policy may override other actions specified. 


The fundamental unit of data transfer within an 
Exchange is the Sequence. The integrity of a 
block of data is verified on a Sequence basis. If 
a Sequence is invalid, the Sequence is aborted 
and the entire Sequence is retransmitted. If an 
Exchange is being managed with a process error 
policy, then accounting for all data is not 
required. However, maintenance of a properly 
functioning Sequence is still required. 


The Sequence’ Recipient shall process 
Sequences within an Exchange in the order 
received. If the order of Sequence processing is 
critical to the Initiator, the Initiator is responsible 
for controlling or verifying the delivery order of 
multiple, consecutive Sequences. The means for 
such control varies by Class of Service. 


29.5.1.1 X_ID processing 


During certain periods in the life of an Exchange, 
one or both X_ID fields are unassigned at the 
beginning or during the Exchange. Both the 
Sequence Initiator and the Sequence Recipient 
shall support the Abort Sequence and the Abort 
Exchange protocols at any point during the 
Exchange. The use of X_ID transition interlock 
and X_ID invalidation are options to help simplify 
this requirement. 


29.5.2 Streaming Sequences 


When a Sequence Initiator streams consecutive 
Sequences without waiting for the terminating 
ACK to the first Sequence, the Sequence Recip- 
ient may have encountered an error condition in 
the first Sequence when the second Sequence is 
initiated. 


The number of open Sequences for a single 
Exchange between two N Ports is limited by the 
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Open Sequences per Exchange value provided 
by the Recipient during Login. Therefore, the 
Sequence Initator is restricted from _ initiating 
more Sequences than allowed by the Recipient 
or an Exchange error is detected by the Recip- 
jent. 


29.5.3 Sequence tracking within 
Exchange 


set = 1 and the corresponding P_Mask bit is 
set = 0. | 
— When a Sequence is terminated abnormally, 


the P_Mask bit corresponding to the SEQ ID 
remains set = 1 and the corresponding 
C Mask is set = 1. 


The resulting status is derived from examination 
of the P_Mask and C Mask in the Exchange 
Status Block for a specific SEQ ID. 


P Mask=0 and C Mask=0 Sequence never opened 
P Mask=0 and C Mask=1 Sequence ended normally 
P Mask=1 and C Mask=0 Sequence active or open 
P Mask=1 and C_Mask=1 Sequence terminated 


Three facilities associated with the Exchange 
Status Block (see 29.11.3) are used to track 
Sequence status throughout an Exchange. 


29.5.3.1 P_Mask 


The P_Mask is a 256 bit vector (8 words) which 
corresponds to the SEQ-ID values of 0 to 255 
where word 8, bit 31 corresponds to SEQ ID = 
0. A P_Mask is defined for each Exchange 
Status Block. 


29.5.3.2 C_Mask 


The C_Mask is a 256 bit vector (8 words) which 
corresponds to the SEQ-ID values of 0 to 255 
where word 12, bit 31 corresponds to SEQ ID = 
0. A C_Mask is defined for each Exchange 
Status Block. 


29.5.3.3 Mask processing 


The following rules apply: 


— When an Exchange is originated, both the 


P_Mask and C_Mask are reset to binary) 


zeros. 

— When a Sequence is initiated, the P_Mask bit 
corresponding to the SEQ ID is set = 1. 

— When a Sequence terminates normally, the 
C_Mask bit corresponding to the SEQ _ ID is 
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abnormally 


A SEQ ID is may be reused within the same 
Exchange if its current ending status indicates 
that it has been completed normally or abnor- 
mally. If the SEQ ID is still open, a frame initi- 
ating a Sequence with the same SEQ ID shall be 
rejected with a reason code of Exchange error. 


29.5.3.4 Sequence Status Blocks 


In addition to the P_Mask and C_Mask, both the 
Originator and Responder shall save a 
Sequence Status Block for each Sequence up to 
the limit of X+2 (where X=value of Open 
Sequences per Exchange). When the limit of 
X+2 is exceeded, the oldest normally completed 
Sequence Status Block is removed. 


29.6 Sequence error detection 


Table 55 summarizes the discussion 


Sequence error detection. 


on 


Table 
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55. Sequence Error Detection/Recovery 


SEQUENCE ERROR RECOVERY 


Action 


Corrupted frame 


Out of order detection 


Frame rejected 


Code violation in frame 


buffer-to-buffer 
Credit Loss 


end-to-end 
Credit Loss 


29.6.1 Sequence timeout 


The basic mechanism for detecting errors within 
a Sequence is the Sequence timeout. Both the 
Sequence Initiator and the Sequence Recipient 
use a timer facility with a_ timeout period 
between expected events. The expected event 
for the Initiator to Data frame transmission is an 
ACK response. The expected event for the 
Recipient is another Data frame for the same 
Sequence. When a Sequence Recipient receives 
the last Data frame (End Sequence) for the 
Sequence, it shall verify that all frames have 
been received before transmitting the final ACK 
for the Sequence. 


If the timeout period expires before’ the 
Sequence is complete, a Sequence timeout is 
detected. The value used for the timeout period 
is local to an N_ Port. Timeouts are detectable 
by both the Sequence Initiator and the Sequence 
Recipient. A Sequence timeout results in 
abnormal termination of a Sequence (see 29.7.1). 
Other mechanisms which detect frame errors 
within a Sequence are performance enhance- 
ments in order to detect an error sooner than 
the timeout period. 


Link timeout (Class 1 


) 


Effects/Recovery 


Out of order detection, 
Abort Sequence,or 
Sequence timeout 


Retransmit or 
Interrogate Status 


Abort Sequence, retransmit 
Abort Exchange (FC-4) 


Out of order detection, 
Abort Sequence, or 
Sequence timeout 


Abort Sequence, 
Reclaim end-to-end Credit 
29.6.2 Out of order 


In Class 1, sequential frame delivery is guaran- 


teed. Therefore, an out of order frame is 
detected by a missing sequence count in con- 
secutive frames received for the same 
sequence. 


In Class 2, sequential frame delivery is not guar- 
anteed. Therefore, an N Port shall use another 
method to detect missing frame sequence 
counts for a Sequence. In order to simplify an 
N_ Port’s implementation, an N_ Port may choose 
to define an out of order window. An N Port 
may choose a window value of W. If the highest 
SEQ CNT received minus W is greater than the 
SEQ CNT of a missing frame, then an out of 
order condition is detected. The value of W is 
only known internally to the N_ Port. 


In all Classes, when an out of order condition is 
detected, the N_ Port shall save the sequence 
count of the missing frame in the Sequence 
Status Block. Only the first error is posted. 
Under the discard policy, the N Port discards 
each successive frame delivered. However, 
ACK processing continues with the Abort 
Sequence Condition bits in F_CTL set appropri- 
ately, beginning with the frame on which the 
error was detected. Once the Abort Sequence 
bits are being set on the ACK frames, each Data 
frame shall be responded to with a separate 
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ACK (either ACK_1 or ACK_N with a one count). 
The Sequence Recipient does not transmit an 
EOFt in response to the last Data frame of the 
Sequence and does not recognize the transfer of 
Sequence Initiative, if present. When the 
Sequence Initiator detects the Abort Sequence 
indication, it transmits an Abort Sequence 
Link_Data request to terminate the Sequence 
(see 29.7.1). 


Under the process policy, the N Port processes 
remaining frames in the Sequence as though the 
error had never occurred. However, the ending 
status posted to the Exchange Status Block shall 
indicate the first error detected and completion 
ending status. The Abort Sequence bits in 
F_CTL are not set for missing frames. However, 
an N Port may request an Abort Sequence for 
other reasons internal to the WN Port or 
sequence processing. 


29.6.3 Frame reject 


All frame rejects result in the Sequence being 
terminated. For Action codes 1 or 2, the 
Sequence is terminated immediately. For action 
codes 3 or 4, the Sequence is terminated using 
the Abort Sequence protocol. Frame rejects with 
action codes of 1 or 3 are retryable if the condi- 
tion indicated by the reason code is corrected. 
Frame rejects for action codes 2 and 4 indicate a 
non-retryable condition which probably results in 
Abort Exchange. 


29.6.4 Frame busy 


In Class 1, an F_BSY or P_BSY indicates a tem- 
porary busy condition which is retryable. The 
Sequence being initiated is immediately termi- 
nated. In Class 2, F_BSY or P_BSY is possible 
in response to any frame. The Sequence Initi- 
ator is responsible for retransmitting the frame 
and the Recipient is responsible for processing 
the retransmitted frame out of order. For Class 
2, a busy response is not considered an error 
condition but is included for completeness as an 
abnormal condition. 


29.7 Sequence recovery 
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29.7.1 Abnormal Sequence termination 


The Abort Sequence protocol is one method by 
which a Sequence may be abnormally termi- 
nated. In the Abort Sequence protocol, the Initi- 
ator transmits an Abort Sequence Link Data 
request to the Recipient to terminate’ the 
Sequence. If the Initiator detects an error in its 
Sequence processing, it performs the Abort 
Sequence protocol. However, if the Initiator has 
transmitted the last Data frame of the Sequence, 
the Sequence may have ended normally. The 
Initiator may choose to interrogate Sequence 
status before aborting the Sequence’ and 
retransmitting. Some applications may require 
interrogation and not allow duplicate’ trans- 
mission. 


If a Sequence Recipient detects an out of order 
or other unusual condition within a Sequence, it 
requests the Initiator to perform the Abort 
Sequence protocol using the Abort Sequence 
Condition bits in F_CTL tn an ACK frame within 
the Sequence which is in error. The Recipient 
may request that a Sequence be aborted and 
retransmitted, or that the Initiator stop the 
Sequence and read status (see 29.6.2). 


However, if no Data frames are being received 
for the Sequence in error, the Sequence Recip- 
ient shall timeout the Sequence, abnormally ter- 
minate the Sequence, update the Sequence 
status in the Exchange Status Block, and release 
link facilities associated with the Sequence 
including the Sequence Status Block (Sequence 
timeout). If a frame for the abnormally termi- 
nated Sequence arrives after termination, the 
Recipient indicates that the Sequence has timed 
out by setting the appropriate Abort Sequence 
Condition bits in F_CTL in the ACK to the frame 
received for the terminated Sequence and the 
frame is discarded. 


In the Abort Sequence protocol, after the 
Sequence Initiator has transmitted the Abort 
Sequence Link Sequence, it retires the SEQ_ID 
of the pending aborted Sequence. Sequence Ini- 
tiative for the Exchange is passed to the Recip- 
ient. In Class 1, the Recipient (new Initiator) 
shall terminate the Sequence and post the 
appropriate Exchange Status Block. The Recip- 
ient transmits an Accept Link Reply Sequence 
returning Sequence Initiative for retransmission 
of the terminated Sequence. The Payload of the 
Accept contains the Exchange IDs~ and 
Sequence _ID of the Aborted Sequence. 


In Class 2, the Recipient shall account for all 
missing frames in the Sequence or wait a 
Sequence timeout period before responding with 
the Accept Link Reply. 


29.7.1.1 End Sequence 


lf the last Data frame of a Sequence has been 
transmitted and the Sequence Initiator detects a 
Sequence timeout, the Initiator shall initiate an 
Exchange with a Read Exchange _ Status 
Link_Data request to determine Sequence and 
Exchange status. If the Initiator is in the process 
of timing out a Sequence for a missing EOFt with 
Sequence Initiative transferred and it receives a 
new Sequence initiated by the Recipient (new 
Initiator), it may assume that the previous 
Sequence ended successfully. 


From a Recipient view, if the last Data frame is 
lost, the Recipient terminates the Sequence 
when a Sequence timeout is detected. 


29.7.2 Credit Loss 


The Standard does not specify the method to be 
employed for Credit allocation to a destination 
N_ Port. If destination N Port end-to-end Credit 
is allocated on a Sequence basis, then that 
portion of end-to-end Credit is reclaimed when 
the Sequence is aborted. When a Sequence is 
aborted, any outstanding ACK frames associated 
with the Sequence being aborted may be 
reclaimed. 
Class 2. 


In addition, with the discard policy in effect in 
Class 1, the Sequence Initiator may reclaim end- 
to-end Credit for missing ACK frames if abort is 
not requested by the Recipient for an ACK fol- 
lowing the missing ACK (i.e. this indicates a lost 
ACK frame and that the Data frame arrived suc- 
cessfully). A similar technique may be applied 
to Class 2 using an out of order Sequence 
window. This may be accomplished dynam- 
ically, or at the normal end of a Sequence. 


This applies to both Class 1 and. 
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29.8 Timeout period 


There are four timeouts defined: 


— Link 

— Sequence 

— Link Recovery 
— OLS transmit 


Each timeout period associated with different 
events may specify a different value or a value 
which represents a common timeout period for 
all events which are timed. The expiration of the 
timeout period may be logically derived from the 
use of one or more physical timers within a spe- 
cific implementation. A specific timeout period 
is not specified by the Standard. 


29.8.1 Timer 


FC-2 uses a 32-bit programmable timer (resol- 
ution to be determined). The programmable 
timer is logically used to notify a link control 
facility if a timeout period has been exceeded by 
a particular procedure or event in process. 


29.9 Link Error Status Block 


Detected errors shall be accumulated in a Link 
Error Status Block. 


The layout is specified in figure 65. 


Link Error Status Block 


Byte 0 1 2 3 


rrrrorrrryrrrr_rrrrauvrrr-v_orrrvyuvrrvrv_uarrrv 


Figure 65. Link Error Status Register 


Specific Bit assignments have not been made. 
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29.10 Frame reception 


Frame reception starts with detection the 
Start_of_ Frame delimiter. Characters are 
received until normal frame reception is termi- 
nated by detection of the End of Frame delim- 
iter. Frame reception is abnormally terminated 
by recognition of any recognized or unrecog- 
nized ordered set. A frame received with a 
proper SOF, EOF, and valid codepoint translation 
is then checked for a valid CRC applied to the 
8-Bit character codes. A frame with a valid SOF, 
EOF, and verified CRC value is designated a 
valid frame and further processing is performed. 


Once frame reception is started, a single code 
violation within the Frame Content is detected 
as an error (code violation is defined by FC-1). If 
the CRC value is incorrect, the frame is consid- 
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ered in error and no further processing is per- 
formed. The EOF type is noted. 


A frame in error is discarded and the appro- 
priate error bit is posted. No further processing 
of error frames is attempted. 


A frame started by SOFc1, SOFx2, or SOFx3 shall 
be responded to by transmission of the R_RDY 
Primitive Signal, regardless of frame validity. 


29.11 Detailed Error detection / 
actions 


29.11.1 Errors detected 


Table 56 lists 10 categories of errors which are 
detectable. The categories specified relate 
directly to link integrity or data integrity as previ- 
ously discussed. 
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Table 56 (Page 1 of 2). Detailed Errors and Actions 


Error Specific Error Seq Init Seq 
Category Action Recp 
Action 
Link Failure Loss of Signal 
Loss of Sync > timeout period 


Link Errors 1. Code Violation during frame reception 
2. Code Violation outside frame reception 
3. Loss of Sync 
4. Invalid Ordered Set 
Link Timeout Class 1: all Sequences timed out 
Class 2 and 3: missing R_RDY 
Link Recovery missing LRR response to LR transmission 
timeout missing Idle response to LRR transmission 
Sequence timeout during Sequence 
Timeout 7 timeout at end of Sequence 
Delimiter Errors Class not supported 
Delimiter usage error (SOFc1 while connected) 
Address Identifier incorrect D_ID 
errors incorrect S_ID 


Frame_Content . CRC 

errors | Busy frame received 

3. Reject frame received 

4. Invalid Type 

5. Invalid Type Modifier 

6. Invalid R_CTL 

7. Invalid F_CTL 

8. Invalid OX_ID 

9. Invalid RX_ID 

10. Invalid SEQ_ID 

11. Invalid SEQ_CNT 

12. Exchange Error 

13. Protocol Error 

14. Data Field too large 

15. Unexpected Link Continue 
16. Unexpected Link_Response 


12 
12 


buffer not available - Class 1 
buffer not available - Class 2 
buffer not available --Class 3 
ABTS frame received 

Out of order error detected 
Missing frame 


Data Frame 
errors 


Np Of RDO] DOMINO DNONNNNNNNONON OO 


Or beh S 


. Out of order error detected 
Abort sequence indicated 
. Missing frame 


ACK_1, ACK_N 
frame errors 


nN 
WN RL AaAhwWN> 
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29.11.2 Actions by Initiator or Recipient 


1. Discard frame 


When a frame is being received which con- 
tains code violation errors, the frame 
reception logic continues to process the 
characters within the frame until frame 
reception is terminated by an EOF delim- 
iter, or another Ordered Set. The 
Frame_Content is discarded, however, the 
delimiters are noted and appropriate action 
taken. The Link Error Status Register is 
updated to record the error. 


If a frame is received with proper delim- 
iters but an incorrect CRC is obtained, the 
frame is discarded. The delimiters are 
noted and appropriate action is taken. The 
Link Error Status Register is updated to 
record the error. 


If the discarded frame was started by an 
SOFc1 and a Dedicated Connection did not 
exist, Link Recovery is performed as 
defined in 27.6. 


If the discarded frame was a Class 1 frame 
which was terminated by an EQOFdt or 
EOFati, all active Class 1 Sequences are 
terminated abnormally. The appropriate 
Exchange Status Blocks are updated and 
the Sequence Status Blocks are released 
for reuse. 


lf a Class 3 frame is received and no 
buffers are available, the frame is dis- 
carded. 


2. Transmit P_RJT frame 
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If a frame other than a P_RJT or F_RJT 
frame is received which contains informa- 
tion in the Frame_Header which is invalid 
or incorrect, a P_RuT frame is transmitted 
with the appropriate reason code as speci- 
fied in 20.3.3.1. Reason codes are prior- 
itized such that the first error encountered 
is returned as the reason code. 


If a P_RJT or F_RJT frame is received 
which contains information in the 
Frame_Header which Is invalid or incorrect, 
the frame is discarded and the Link Error 
Status Register is updated. 


During a Class 1 Dedicated Connection, if a 
Data frame is received and no buffer is 
available, this indicates that the transmitter 
has an end-to-end Credit tracking problem. 


The Frame_Header is retained in order to 


- generate a P_RJT while the remainder of 


the Frame Content is discarded. The 
reason code in P_RJT shall indicate ’pro- 
tocol error” and the Abort Sequence Bits 
shall be set in order to request the 
Sequence Initiator to Abort the Sequence. 


3. Process Reject 


When a P_RJT or F_RJT frame is received 
in response to a frame transmission, it 
shall be passed to the appropriate Upper 
Level Protocol in order to process. Certain 
errors are recoverable by taking an appro- 
priate action, such as_ Login. The 
Sequence shall terminated or aborted 
using the Abort Sequence Protocol, regard- 
less of possible recovery actions. For most 
non-retryable errors the Exchange shall 
also be aborted. 


4. Transmit P_BSY frame 


An N_Port shall track the status of its 
buffers such that if a Class 2 Data frame is 
received and no buffer is available, a 
P_BSY ts returned to the transmitter of the 
frame. Portions of the frame other than the 
Frame Header are discarded. The 
Frame_Header is captured in order to gen- 
erate a proper P_BSY Link Response 
frame. 


If an N Port receives a Class 1 connect- 
request frame and its internal link facilities 
are busy or unavailable, the N Port 
responds by transmitting a P_BSY frame 
with the appropriate reason code (see 
20.3.3.2.) with EOFdt and discards the 
connect-request frame. 


5. Process Busy 


When an F_BSY or P_BSY is received in 
response to a Class 1 connect-request, the 
N Port may: 


— attempt a connect-request to a different 
destination N_ Port if such a request is 
pending, 

— delay a period of time before reissuing 
the connect-request, or 

— immediately reissue’ the 
request. 


connect- 


The decision as to which action to take is 
dictated based on the conditions in the 
N Port and the period of time lost if 
another busy condition is returned. 


ees ee ee ses — ———. <_< as se 


When an F_BSY or P_BSY is received in 
response to a Class 2 frame, the N_ Port 
shall retransmit the frame which was 
busied. In order to avoid reissuing a frame 
for an extended number of retries an 
N Port may choose to count the number of 
retries and decide to shutdown communi- 
cation with a specific N_ Port. 


6. Perform Link Recovery Protocol 


When an N Port has reached a buffer-to- 
buffer Credit CNT of zero and_ has 
exceeded the Link timeout period, a Link 
timeout is detected. In Class 1, tf an 
N_ Port has timed out all active Sequences, 
a Link timeout is detected. When a Link 
timeout is detected, the N Port or F_Port 
begins the Link Recovery Protocol. 


In addition, in Class 1 an N Port may not 
know whether a Dedicated Connection 
exists or not. An N Port may initiate the 
Link Recovery Protocol in order to reach a 
known state. 


7. Set Abort Sequence Bits 


When a Sequence Recipient detects a 
Sequence error from out of order detection 
or other internal processing errors, the 
Recipient sets the appropriate Abort 
sequence in F_CTL bits 5-4. 


00 Continue Sequence 

0 1 Abort Sequence and retransmit 
10 Stop Sequence and read Status 
1 1 Sequence timeout by Recipient 


The SEQ CNT of the frame in which the 
“out of order” condition was detected is 
saved in the Sequence Status Block. Only 
the first error is saved in the Sequence 
Status Block. This information may or may 
not be required by the Sequence Initiator 
for recovery purposes. 


8. Perform Abort Sequence Protocol 


When a Sequence Initiator detects a 
Sequence error or receives an appropriate 
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Abort Sequence indication in F_CTL bits 5-4 
in an ACK for an active Sequence, the Initi- 
ator transmits an Abort Sequence 
Link Data request to the Recipient and 
transfers Sequence Initiative in order to 
complete Abort Sequence processing. See 
29.7.1. 


9. Abnormally terminate Sequence 


10. 


11. 


12. 


13. 


14, 


When a Sequence Recipient detects a 
Sequence timeout and no Data frames are 
being received for the Sequence, the 
Recipient shall terminate the Sequence 
and update the Exchange Status Block. 


When a Class 1 Dedicated Connection is 
removed by an EOF delimiter or a Primitive 
Sequence, the N_ Port shall abnormally ter- 
minate any active Sequences. See 29.7.1. 


Retry Sequence 


When a Sequence has been abnormally 
terminated, the Sequence Initiator shall 
retransmit the Sequence. 


Update LESB 


The Link Error Status Block is updated to 
track errors not directly related to an 
Exchange. 


Perform Link Failure Protocol 


The Link Failure Protocol is initiated by 
transmission or reception of the Not Opera- 
tional Primitive Sequence. 


Error Policy processing 


When an error is detected within a 
Sequence, the Sequence is either proc- 
essed normally (process policy), or dis- 
carded (discard policy). See 29.6.2. 


Read Status Block 


Read Status Block (either Sequence or 
Exchange) is accomplished a Sequence 
using the appropriate Link Data request. 
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29.11.3 Exchange Status Block 


When a Read Exchange Status Block request is 
received, the following Payload is transmitted in 
the Accept Reply Sequence. The content is 
specified in the arrangement shown in figure 66. 
The Exchange Status Block is a logical construct 
and does not require specific hardware facilities. 


Following transmission of word 15, a list of 
sequence Status Blocks up to a count of X+2 is 
provided. The ordering of the list of SSBs is 
from the oldest to the newest. 
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Word 


10 


11 


12 


13 


14 


15 


16 


17 


31 
rrerrrrr| 


31 6) 
E STAT 

31 0 
reserved 

31 0 


31 


Word O0-Class Service Parameters 


Word 1-Class Service Parameters 


Word 2-Class Service Parameters 


Word 3-Class Service Parameters 


P_ Mask 


SEQ_ID 


31 


Oldest Sequence Status Block 


SEQ. 1D | S STAT | ERROR SEQ_CNT 


31 


31 


reserved | HIGHEST SEQ_CNT 


Newest Sequence Status Block 


SEQ_1D | S_STAT | ERROR SEQ CNT 


31 


reserved | HIGHEST SEQ CNT 
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Figure 66. Exchange Status Block | 29.11.4 Sequence Status Block 


29.11.3.1 E_STAT 


Bit 31 - Exchange owner 


0 


— 0 Originator SEQ_ID | $_STAT | ERROR SEQ_CNT 
— 1 Responder 

31 0 
Bit 30 - Sequence Initiative reserved | HIGHEST SEQ_CNT 


— Q Other Port holds initiative 
— 1 This Port holds initiative 


Bit 29 - Class 1 
— 0 not Class 1 | 29.11.4.1 S_ STAT 
— 1 Class 1 


Bit 28 - Class 2 


| Figure 67. Sequence Status Block 


| Bit 23 - Sequence context 


| — 0 Initiator 
— 0 not Class 2 | — 1 Recipient 


— 1 Class 2 
Bit 27 - Class 3 


| Bit 22 - Completion 


| — 0 active 
— 0 not Class 3 | — 1 complete 


— 1 Class 3 
Bit 26 - Completion 


| Bit 21 - Ending Condition 


| — 0 normal 
— 0 active | — 1 abnormal 


— 1 complete 
| Bit 20 - Error type 
Bit 25 - Ending Condition 
| — 0 aborted by initiator 


— Q normal | — 1 timed out by recipient 
— 1 abnormal 
| Bit 19 - Error Policy 
Bit 24 - Error type 
| — 0 discard 
— Q aborted by initiator | — 1 process 


— 1 timed out by recipient 
Bit 23 - Error Policy 


— Q discard 
— 1 process 


Bit 22 - Originator X_ID invalid 


— Q Originator X_ID valid 
— 1 Originator X_ID invalid 


Bit 21 - Responder X_ID invalid 


— 0 Responder X_ID valid 
— 1 Responder X_ID invalid 


Bits 20-0 - Reserved 


| Bits 18-16 - Reserved 
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Annex A. Test methods (informative) 


This annex is not part of the standard but is 
included for information purposes only. This 
section is referenced by and applies to FC-O. 


This annex defines terms, measurement tech- 
niques, and conditions for testing jitter and 
optical waveshapes. This annex deals with 
issues specific to Fiber Channel and is not 
intended to supplant standard test procedures 
referenced in the specifications. In cases where 
there are conflicts between this annex and the 
referenced standard this annex shall take pre- 
cedence. The annex directly applies to verifying 
node performance related to the Optical Inter- 
face Specifications. 


These same _ procedures may be_ used to 
measure a single component of the system. 
Component performance is outside the scope of 
Fiber Channel compliance but it is useful from a 
design viewpoint. A later annex provides 
exemplary information on how to interpret com- 
ponent measurements. 


A.1 Active output interface 


A.1.1 Optical power measurement 


Section 6, specifies the average optical power 
launched into a fibre conforming to section 8. 


The measurement shall be made with the node 
transmitting an idle sequence. The measure- 
ment shall be made by the methods of 
EIA/TIA-526-2 ”“OFSTP-2, Effective Transmitter 
Output Power Coupled Into Single-Mode Fibre 
Optic Cable”. 


A.1.2 Optical Spectrum Measurement 


The center wavelength and = spectral width 
(FWHM or RMS) value of the Active Output Inter- 
face can be measured as appropriate using an 
optical spectrum analyzer per FOTP-127. The 
patch cable used to couple the light from the 
Active Output Interface to the spectrum analyzer 
should be short to minimize spectral filtering by 
the patch cable. The output signal during the 
measurement shall be any valid 8B/10B code 
pattern. 
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A.1.3 Optical waveform 


A.1.3.1 Mask of the eye diagram (laser) 


The mask of the eye diagram for the laser trans- 
mitters may be measured using a receiver with 
a fourth-order Bessel-Thompson transfer func- 
tion given by: 


105 


os 2 3. 4 
105 + 105y + 45y" + 10y~ + y 


p= 


With y = 2.1149, p= ——, 


f, = 0,75 x Bit Rate 


Note - This filter is not intended to represent the 
noise filter used within an optical receiver but is 
to provide a uniform measurement condition. 


The nominal attenuation at the reference fre- 
quency, f,, is 3 dB. The corresponding atten- 
uation and group delay distortion at various 
frequencies is given below: 


Table 57. Transmit pulse noise filter 


fif _ fif Attenuation) Distortion 
(dB) (Ul) 


The mask of the eye diagram is intended to 
measure the waveshape properties of the optical 
signal such as rise/fall time, overshoot, under- 
shoot, and ringing. As such this test applies to 
the deterministic portion of the waveform and 
does not include random noises in either time or 
amplitude. 


| 
| 
| 
| 
| 
| 
| 
| 


In order to set up the mask the magnitude of the 
one and zero logic levels is required. These may 
be determined from the average value of the 
signals at the 50% time point in a bit cell. If 
these values are obtained from a measurement 
system which preserves the amplitude informa- 
tion these values may be used to determine the 
extinction ratio. 


A.1.3.2 Pulse Parameters (LED) 


Optical waveform measurements shall be shall 
be measured using a DC coupled wide band- 
width opto-electronic receiver and an 
oscilloscope. The signal during the measure- 
ment shall consist of a sequence of K28.7 data 
bytes. This pattern corresponds to a square 
wave at 10% of the Bit Rate. It is important that 
the receiver’s frequency response, gain flatness 


and linearity over the range of optical power 


being measured be sufficient to provide accurate 
measurement of the 0% and 100% levels and to 
yield accurate optical rise and fall times and 
minimum distortion of the optical pulse. A 
minimum frequency response of five times the 
data rate is required. In the event of a noisy 
optical waveform, optical detector, or 
oscilloscope front end the use of a digital sam- 
pling oscilloscope operated in the averaging 
mode to reduce the noise is recommended. 


The Active output interface extinction ratio is a 
measure of the modulation depth of the optical 
waveform exiting the node. The extinction ratio 
is the ratio of voltage corresponding to the 0% 
level (low light) to the voltage corresponding to 
the 100% (high light) level. 


A.1.4 Jitter measurements 


The Active Output Interface jitter specifications 
apply in the context of a 10-'2 bit error rate 
(BER). Jitter may be measured with a digital 
oscilloscope, or a bit error rate tester (BERT) as 
described in sections A.3 and A.4. 


A.2 Active input interface 


The Active Input Interface sensitivity shall be 
measured by the methods of EIA/TIA-526-3, 
“OFSTP-3, Fibre Optic Terminal Equipment 
Receiver Sensitivity and Maximum Receiver 
Input”. The source of the Active Input Interface 
test signal shall be any optical source con- 
forming to the worst case limits of the Active 
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Input Interface specifications of the media under 
test. 


The test shall be performed with traffic con- 
sisting of frames of data so that the receiving 
equipment may perform its normal synchronizing 
operations. The frame contents shall consist of 
an encoded pseudo random pattern whose 
length is at least 1000 bytes long. The purpose of 
this pattern is to provide frequency components 
in the data which span the full frequency range 
of the clock recovery system. The contents of the 
frame shall end with a positive running disparity 
so that the K28.5 character in the first position of 
the EOF delimiter will be present in the comple- 
ment form from the K28.5 character in the first 
position of the SOF delimiter. 


A compliant node shall receive the test signal 
over the range of conditions specified with a 
frame error rate that corresponds to a BER less 
than or equal to 10-. The requirements in 
section 6 were written in terms of BER to facili- 
tate to the specification of components to be 
used in a particular implementation. 


The characteristics of the test signal may be 
measured with the methods outlined in sections 
A.1, A.3, and A.4. Components used in a partic- 
ular implementation may also be measured with 
these methods. 


A.3 Distortion and jitter contributions 


Optical waveform distortion and jitter are meas- 
ured as the deviation from the ideal time posi- 
tion of the signal at the 50% point of the signal. 
The 50% is identified as the zero crossing of the 
AC coupled signal. The zero level is established 
in absence of the signal. 


There are two types of jitter specified in the FC 
specifications. The definitions and contributing 
factors are given below and the test methods 
are given in section A.4. 


Deterministic jitter (DJ) Timing distortions 
caused by normal circuit effects in the 
transmission system. Deterministic 
jitter is often subdivided into duty 
cycle distortion (DCD) caused by 
propagation differences between the 
two transitions of a signal and data 
dependant jitter (DDJ) caused by the 
interaction of the limited bandwidth of 
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the transmission system components 
and the symbol sequence. 


Random jitter (RJ) RJ is due to noise contrib- 
utions in the optical receiver and 
mode partition noise effects on long 
single mode links. RJ is modeled as a 
Gaussian process which will average 
to zero. It shall be characterized by 
the peak to peak value at a 10-” 
probability. The peak to peak value is 
14,0 times the RMS jitter value. 


A.4 Distortion and jitter 
measurement 


In this standard there are two methods used to 
specify jitter. The LED based systems specify DJ 
and RJ separately. The laser based systems 
combine the two components into a single meas- 
urement of the eye opening. This is the interval 
in the bit time which is error free to BER<10-12. 


A.4.1 Measurement system 
The  opto-electronic measurement = system 


described in section A.1.3 shall be used for jitter 
measurement. 


A.4.2 Active output interface eye 


opening measurement 


The Active Output Interface (AOI) optical eye 
opening measurement involves measuring the 
open eye of the AOI on a bit by bit basis using a 
BERT (BIT Error Rate Test) test set. The BER is 
measured at various T,’s (decision points) within 
the eye pattern to insure conformance to the eye 
opening specification in tables 5 and 6 of the 
standard. 


The eye opening is given by: 
EW = |T,( max) — To] +|7, — Tg{ min)| 
Where: 


To 


center of the eye pattern, 


BER decision point as referenced 
from To, 
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Tf max) 
= rightmost decision point, and 
Tg{ min) 


= leftmost decision point. 


For each position of Ty from T,(min) to Tz (max) a 
BER measurement is taken, giving the proba- 
bility of error at the Ty position. In effect Ty, is 
swept across the eye pattern, measuring the 
probability of error at each point in the eye. The 
range of 7, values that result in a BER < 10-* 
establishes the eye opening and the smallest 
range from T, must be > half the appropriate 
eye opening specification. 


In practice, a BER Test set is used to generate 
and sweep the decision point (using the BERT 
clock in conjunction with a precise delay gener- 
ator), to make the bit by bit error count, and to 
calculate the measured BER. The center of the 
eye (T,) pattern is the midpoint between posi- 
tioning T, to the left and right edges of the eye to 
achieve a BER >10-%. The measured BER at 
To, Tai Max), Tai min) must be <10-' and the 
values of both (Ta( max) — 7,) and (7, — Ta({ min)) 
must be greater than or equal to half the appro- 
priate eye-window specification in tables 5 and 6 
of the standard. All measurements are made 
with respect to a low pass forth-order Bessel- 
Thompson filter (described elsewhere in this 
annex) or equivalent. It is important that the 
BERT retiming data latch be significantly faster 
than the timing resolution of interest. 


A common practice used to save time is to 
measure the eye opening at higher probabilities 
(e.g. 10-§) and then extrapolate to the eye 
opening at a 10-" probability. 


A.4.3 DJ measurement 


A digital sampling oscilloscope may be used to 
measure DJ with a test pattern consisting of 
repeating K28.5 data bytes. Synchronize the 
oscilloscope to the pattern repetition frequency 
and average the waveforms to remove the 
effects of random jitter and noise in the meas- 
urement system. In the 20 bit pattern there will 
be five positive transitions and 5 negative transi- 
tions. Measure the time of the 50 % crossing of 
all 10 of the transitions. The time of each 
crossing is then compared to the mean expected 
time of the crossing and a set of ten timing vari- 


ations are determined. The DJ is the range of 
the timing variations. 


A.4.4 RJ measurements 


If a digital oscilloscope is available which has 
the capability of measuring time statistics the RJ 
may be determined by applying a sequence of 
K28.7 data bytes. The oscilloscope is used to 
determine the standard deviation of the 50% 
crossings. The Random Jitter at 10-' will be the 
+/- 7 sigma limit points of the distribution. 


An alternate method is to measure the eye 
opening by the method of section A.4.2 and sub- 
tract the DJ contribution as measured in section 
A.4.3. 


A.5 Relative intensity noise (RIN) 
measuring procedure 


A.5.1 Test objective 


When lasers which are subject to reflection 
induced noise effects are operated in a cable 
plant with a low optical return loss the lasers 
will produce an amount of noise which is a func- 
tion of the magnitude and polarization state of 
the reflected light. 


The magnitude of the reflected light tends to be 
relatively constant. However, the polarization 


state varies significantly as a function of many 


cable parameters, particularly cable placement. 
In a cable plant which is physically fixed in place 
the variation is slow. If the fibre is subject to 
motion, such as occurs in a jumper cable, the 
change may be sudden and extreme. The effect 
is unpredictable changes in the noise from the 
laser with the result that the communication link 
may exhibit sudden and unexplainable bursts of 
errors. 


The solution to this is to assure that the lasers 
used do not generate excessive noises under 
conditions of the worst case combination of 
polarization and magnitude of reflected optical 
signal. 


The noise generated is a function of the return 
loss of the cable plant. For the Fiber Channel the 
specified return loss is 12 dB resulting in the 
notation of RIN,» for the relative intensity noise. 
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A.5.2 General test description 


The test arrangement is shown in Figure 68 The 
test cable between the Device Under Test (DUT) 
and the detector forms an optical path having a 
single discrete reflection at the detector with the 
specified optical return loss. There must be only 
one reflection in the system as the polarization 
rotator can only adjust the polarization state of 
one reflection at a time. 


Two measurements are made by the 
photodetector. The average optical power is 
determined by measuring the average current, 
Ipd, through the detector. 


The second measurement is the noise, which is 
measured by AC coupling the detector into the 
high frequency electrical power meter. If 
needed, an amplifier may be used to boost the 
signal to the power meter. 


A low pass ffilter is used between the 
photodetector and the power meter to limit the 
noise measured to the passband appropriate to 
the data rate of interest. 


In order to measure the noise the modulation to 
the DUT must be turned off. If the laser is modu- 
lated the modulation power will be measured by 
the power meter rather than the noise power. 


A.5.3 Component descriptions: 


Test Cable The test cable and detector combina- 
tion must be configured for a single 
dominate reflection with an _ optical 
return loss of 12dB. (The Optical 
return loss may be determined by the 
method of FOTP-107) ‘If multiple 
lengths of cable are required to com- 
plete the test setup they should be 
joined with splices or connectors 
having return losses in excess of 30 
dB. The length of the test cable is 
not critical but should be in excess of 
2 meters. 


Polarization Rotator The _ polarization rotator 
must be capable of transforming an 
arbitrary orientation elliptically 
polarized wave into a fixed orien- 
tation linearly polarized wave. A 
polarization rotator consisting of two 
quarter wave retarders will have the 
necessary flexibility. A possible con- 
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Detector Bias Supply 


Current 
Meter 
(Ipd) 
Polarization 
Rotator 


Device 
Under 
Test 


Single~Mode Amplifier 


Fibre 


Figure 68. RIN Test Setup 


struction technique is = given” in 
H.C.LeFever, "Single Mode Fibre 
Fractional Wave Devices and 
Polarization Controllers,” Electronics 
Letters, Vol. 16, No. 10, pp 778-780, 
September 25, 1980. 


Detector and Detector/Amplifier The detector 
may be of any type which is sensitive 
to the wavelength range of interest. 
The frequency response of the | 
detector must be higher than the 
cut-off frequency of the low pass filter. 


The detector shall be capable of 
determining the average and _ vari- 
ation of the optical signal. Typically 
the average optical power is deter- 
mined by the current, Id, through the 
diode. The detector assembly shall 
have an effective output impedance of 
50 Q. 


If necessary, the noise may be ampli- 
fied to a level consistent with accu- 
rate measurement by the power 
meter. 


Filter The low pass filter shall have a 3dB 
bandwidth of approximately 70% of 
the bit rate. Recommended values 
are shown in table 178. The total 
filter bandwidth used in the RIN calcu- 
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Low Pass 
(Optional) -_ Fitter aa 


lation must take the low frequency 
cut-off of the DC blocking capacitor 
into consideration. 


Table 58. Filter 3 dB point 


Filter 3 dB Point 


200 MHz 
400 MHz 
750 MHz 


The filter shall be placed in the circuit 
as the last component before the 
power meter so that any high fre- 
quency noise components generated 
by the detector/amplifier are elimi- 
nated. If the power meter used has a 
very wide bandwidth care should be 
taken in the filter selection to ensure 
that the filter does not lose its 
rejection at extremely high frequen- 
cies. 


Power Meter The power meter should be an RF 


type designed to be used in a 50 Q 
coaxial system. The meter must be 
capable of being zeroed in the 
absence of input optical power to 
remove any residual noise from the 
detector or its attendant amplifier, if 
used. 


A.5.4 Test Procedure 


1. 


Connect and turn on the test equipment. 
Allow the equipment to stabilize for the man- 
ufacturers recommended warm up time. 


. With the DUT disconnected zero the power 


meter to remove the contribution of any 
noise power from the detector and amplifier, 
if used. 


. Connect the DUT, turn on the laser and 


verify that the optical output is within normal 
operation range by means of the detector 
current. The laser should not be modulated. 


. Operate the polarization rotator while 


observing the power meter output to maxi- 
mize the noise read by the power meter 


. Calculate RIN from the observed detector 


current and electrical noise by use of the 
equation: 
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Pe 
RIN = 10 log ——-— — G aB/Hz 
i 


Where: 
RIN = Relative Intensity Noise 


/ 


pd 
= Current through the detector (A) 
Pe 
= Electrical noise power in Watts 
BW 
= Bandwidth of the measuring system (Hz) 
= Low Pass Bandwidth of filter - High Pass 
Bandwidth of DC blocking capacitor. 
G 


= Gain in dB of any amplifier in the Noise 
Measurement path | 
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Annex B. Alternative cable plant usage (informative) 


This annex is not part of the standard but is 
included for information purposes only. 


In some cases, it will be desirable to use an 
alternative multi-mode cable plant to those 
described in sections 8.2 and 8.3. This may be 
due to the need for extended distances or for 
operation in locations where alternative cable 
plants are presently installed. These fiber types 
have not been studied and details for their use is 
not provided for in the main body of the specifi- 
cation. Therefore, using these fibre types may 
change the maximum achievable’ distance 
between nodes. 
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Table 59. Alternative fibre types 
Nomenclature Primary Fibre 
Clause Type 


2 
a) 


50-M6-SL-I 
25-M6-SL-| 
25-M5-LE-| 
12-M5-LE-L 


2m-1Km 
2m-2Km 


rea | stm 


Note: These cases will have to be treated on an 
individual basis. See Annex D for methods of 
computing distances. 
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Annex C. Electrical interface example (informative) 


This annex is not part of the standard but is 
included for information purposes only. 


This annex describes an example implementa- 


tion of the electrical interfaces for optoelectronic — 


modules to meet the requirements of the Fibre 
Channel. This is a minimum set of requirements 
and it is recognized that individual implementers 
may desire to provide features in excess of this 
minimum set to accomplish additional system 
functions or as an aid to testing. 


A block diagram of the modules is shown in 
Figure 69. It is option of individual imple- 
menters to place all or part of the function in a 
product. Because of this individual products 
may not have all of the interfaces exposed. Any 
unexposed interface is under no obligation to 
conform to this example. 


This is an example only. Conformance to this 
example is not required for Fibre Channel con- 
formance. Fibre Channel conformance is 
obtained by conformance to the requirements of 
the main body of this standard. 


+/-Rcev_Data 


Receiver Clock 


It is realized that differing communications 
media will require differing controls. For this 
reason this example limits itself to consideration 
of only the data interface and those control func- 
tions which will be common over all media. 
Therefore, the block labeled “Media Control” in 
Figure 69 will not be described in this example 
along with it’s related signals Media Control and 
Media_Status. 


The example includes the majority of the func- 
tion of the FC-O layer and a portion of the FC-1 
layer. 


C.1 Communications Levels 


Two communications levels are employed. The 
high speed, full data or clock rate, signals are 
implemented in differential ECL. The lower 
speed lines associated with the parallel data 
transfers and function controls are implemented 
in TTL compatible voltage levels. 


+/-Retime Data 


Read Byte Clock 0 
Serial Read Byte Clock 1 


Recovery |+/-Retime Clock} to > 


Media 
Signal Transmitter |< 
Out +/-Trans Data 


Media 
Control 


Parallel |+++++++ Rec Data Byte i 
(w/Byte 
Align) Byte Sync 
Enable Byte Sync 


Lock_to_ Reference 


Loopback Enable 
Transmit_Byte_ Clock 


Trans Data_Byte_j 
Serial 


Signal Detect 


Media_Control 
Media Status 


Figure 69. Fibre Channel Implementation Block Diagram 
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C.1.1 ECL 


The high speed communication of the serial data 
and clock are implemented in differential ECL. 
The signal swings are shown in Figure 70 refer- 
enced to the most positive voltage driving the 
ECL interface circuits. This voltage could be 
either ground, in the case of conventional nega- 
tive ECL, +5,0 volts, in the case of positive ref- 
erenced ECL. These outputs should be capable 
of driving 50 © transmission lines terminated in 
50 © to 2,0 volts below the reference level. The 
drivers and receivers are intended to operate 
only within the package and are not required to 
have the electrostatic discharge protection 
required for driving box to box cables. 


MPUL Vref-0,88V 


LPUL Vref-1,03V 


MPDL Vref-1,63V 


LPDL Vref-1,81V 
OUTPUT LEVELS 


MPUL Vref-0,88V 


LPUL Vref-1,17V 


MPDL Vref-1,48V 


LPUL Vref-1,81V 
INPUT LEVELS 


Figure 70. ECL Communications Levels 


C.1.2 TIL 


The parallel communications and control lines 
are implemented in TTL compatible voltage 
swings as shown in Figure 71 in order to provide 
compatibility with the widest number of logic 
technologies in the host system. Due to the rel- 
atively high speeds of the signals, especially the 
byte clocks in the 1,0625 GBit/s systems, the use 
of series resistors in the driver outputs is 
strongly recommended to minimize ringing. 
Because of this, the current capability of the 
drivers has been reduced to allow adequate 
output voltages in the presence of an output 
resistor. 
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MPUL 3,8V 


LPUL 2,4V (4ma) 


MPDL 0,4V (4ma) 


LPDL OV 
OUTPUT LEVELS 


MPUL 3,8V 


LPUL 2,0V 


MPDL 0,8 V 


LPDL OV 
INPUT LEVELS 


Figure 71. TTL Compatible Communications 
Levels 


C.2 Serial Interfaces 


All serial interfaces communicate on differential 
ECL communication levels. 


C.2.1 Transmit Serial Interface 


The transmit serial interface communicates the 
data from the serializer to the communications 
media. It corresponds to the FC-0_Data.Request 
primitive of the FC-O Service Interface. 


C.2.2 Receive Serial Interface 


The receive serial interface communicates the 
received data from the media interface circuits 
to the clock extraction and retiming circuits. 


C.2.3 Receive Retimed Serial Interface 


The receive retimed data carries the data and 
recovered clock from the clock recovery circuits 
to the deserializer. 


C.2.3.1 Retimed_Data 


The Retimed Data lines are an implementation 
of the FC-O0 Data.indication primitive of the FC-0 
service interface. 


C.2.3.2 Retimed_Clock 


The Retimed Clock lines carry the clock signal 
recovered from the Receive Serial Interface to 
the deserializer. This line is the implementation 
of the FC-O_Clock_Out.Indication primitive of the 
FC-O service interface. 


C.2.3.3 Retimed Serial Interface Timing 


The relative timing between the Retimed Data 
and the Retimed_Clock are shown in Figure 72. 


—_ Thit I 


Retime Clock | | | 


0.25 Thit pelea 0.25 Thit 


Retime_Data LL ee 


Figure 72. Retimed Interface Signal Timing 


C.3 Parallel Interfaces 


The parallel interfaces are implemented using 
TTL compatible voltage levels. 
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C.3.1 Bus width 


The example allows for bus widths of either one 
or two bytes depending on data rate. The 265,625 
MBit/s rate utilized a one byte wide bus, while 
the 1,062 5 GBit/s rate utilizes a two byte bus. 


C.3.2 Transmit Parallel Interface 


The transmit parallel interface timings are 
shown in Figure 73. The data transfers are 
timed by the host system supplied 
Transmit_ Byte Clock which also acts as a fre- 
quency reference for the transmit serial data and 
the receiver clock extraction circuitry. Data 
transfers are timed from the rising edge of the 
clock. A one byte interface would use the 
Trans Data Byte 0 timings and a two byte inter- 
face would use both timings. 


In the case of the two byte interface the two data 
fields are to be clocked into the optoelectronic 
module alternately. The module timing is 
arranged to allow the system to switch both 
bytes together if desired. 


—_ Tcyc a 


Transmit _Byte Clock | | | | | 


| 
0.1 Tcyc —>| 


|<«——>|- 0.2 Tcyc 


|<— 0.5 Tcyc ——>| 


Trans Data Byte.© /| vALIO |//////MMIMMNIUMIIIUIVIMI| vaio {11111 


0.1 Tcyc 


Trans Data Byte 1 


ITLTLLLTTLTTTLLT TTL TT 


—» +— 
<—+>|— 0.2 Tcyc 


VALID PS/LI/II/LLTLTLTLLLTT TLL 1 11 


Figure 73. Parallel Transmit Data Interface Timing 
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[—_ Tcyc aii 


Read Byte Clock | | | 
Read Byte Clockl | | | 


0.1 Tcyc —_ m 0.4 Tcyc md 


Rec _Data_syteo —////| vaio. | //A////IINIIIIII11| VALID 


0.1 Tcyc = << 0.4 Tcyc | 


Rec Data Byte 1 


TLL MANNII 


Figure 74. Parallel Receive Data Interface Timing 


C.3.3 Receive Parallel Interface 


The receive parallel interface timings are shown 
in Figure 74. In the case of a two byte interface 
two receive byte clocks are generated by the 
optoelectronic module to simplify system 
timings. The bytes are presented alternately to 
reduce simultaneous switching noise. 


In the case of a one byte interface only 
Read Byte Clock_0 and Rec _Data_Byte_0 are 
required. 


The data bytes are valid about the negative edge 
of their respective Read_Byte_Clocks. 


C.4 Transmit Clock Reference 


The Transmit_Byte Clock forms the reference for 
the data rate synthesizer. The timing is per- 
formed from the leading edge which must have 
low jitter. This line performs the function of the 
FC-O0 Clock_Reference.Request primitive of the 
FC-0 Service Interface. 


C.5 Control and Status Interface 


The control and status lines are implemented in 
TTL compatible communications levels. 
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C.5.1 Receive Bit Sync Acquire 


The receive interface bit synchronization is 
under control of the host system. When the FC-1 
layer wishes to acquired bit synchronization the 
following sequence is followed: 


1. Bring Lock_to_Reference line positive. 


2. Wait 2,500 bit times for the PLL to lock to the 
reference frequency provided by the 
Transmit_Byte_Clock. 


3. Bring Lock_to_ Reference line negative. 


4. Wait 2 500 bit times for the PLL to lock to the 
incoming data. 


Should synchronization be lost while the PLL is 
operating near to the data frequency the clock 
recovery will take less than 2 500 bits to reac- 
quire synchronization. This may occur as a 
result of a phase jump in the incoming data or 
activation of the loopback function. 

This bit synchronization activity results in estab- 
lishing the frequency and timing of the 
Retime_Clock which in turn drives’ the 
deserializer and hence the Read_Byte_ Clocks. 
In the event that the incoming signal is lost the 
activity of the Retime Clock is undefined. Under 
these conditions the frequency or other activity 
of the Read Byte Clocks is undefined. 
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Sync Byte Detected | | 


Possible Short 
Clocks 


Read Byte Clock 


/TTf/ sor Veye 


| nas Tcyc anata 


.9 TCyc 


Read Byte Clockl ///// 


0.1 Tcyc aid _ 0.4 Tcyc ~ 


Rec Data Byte © //////I\/MININININIIIIIN| valid = // IIMA 


Rec Data Byte L0 S////PL/N/L/LLL/ITLLL LLL TTLLLL TTL TTL LLL 117 


Byte Sync 


0.1 Tcyc me +— 0.4 Tcyc _ 


VALID 7 


Figure 75. Parallel Receive Data Interface Timing 


The Lock_to_Reference line is the implementa- 
tion of FC-O Resync.Request primitive of the 
FC-0 service interface. 


C.5.2 Receive Byte Alignment 


The optoelectronic module contains circuitry to 
provide byte alignment. The circuitry will cause 
the output to be aligned on any occurrence of 
the alignment pattern in the incoming serial data 
stream. The alignment pattern is defined as the 
COMMA sequence of the 8B/10B code. This is 
either of the ten bit sequences 0011111XXX or 
1100000XXX. These sequences contain the first 
seven bits of the K28.5 special character in both 
disparities. 


When alignment occurs the byte of the incoming 
data which triggered the alignment will be pre- 
sented in uncorrupted form on the parallel data 
out lines. In the case of a two byte interface the 
byte which triggered the alignment data will be 
presented as Rec_Data_Byte_0. 


When the byte alignment pattern is detected in 
the incoming data stream the Read_Byte_Clocks 
are forced to an initial state. The state is unde- 
fined except for the following: When the clock 
sequence resumes there shall be at least one 
full half width of the Read Byte Clock prior to 
the clock edge about which the data is valid. 
This is iNtustrated in Figure 75. 


The occurrence of a byte alignment is signaled 
by a pulse on the Byte Sync line. The pulse will 
have a nominal leading edge position coincident 
with the nominal rising edge timing of 
Read Byte ClockO. The falling edge of the pulse 
will have a nominal timing coincident with the 
following rising edge location of 
Read Byte Clock0. Due to implementation 
dependant timing skews the actual relative 
timing between Read Byte Clock0O and 
Byte Sync will vary with the implementation. 


This line signals the using system that the pre- 
sented byte is the first byte of an ordered set as 
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defined by FC-1 and that the previous clocks 
may have been shortened. 


The alignment is enabled by holding the 
Enable Byte Sync input high. This allows the 
byte alignment to be disabled for test purposes. 
Alternately, the byte alignment may be enabled 
in single acquire mode by lowering the 
Enable Byte Sync input in response to a 
Byte Sync output. 


It should be noted that if the byte sync is 
enabled the internal circuits will respond to any 
occurrence of the alignment pattern in the input 
data stream. This may result in two anomalous 
situations. A single bit error may cause the 
alignment pattern to be falsely detected out of 
position. If the byte sync is enabled an align- 
ment to a false boundary will occur with the 
resulting destruction of all data until a properly 
located alignment pattern is detected. Secondly, 
under an open link condition the thermal noise 
of the receiver may cause many false locks to 
occur. The Byte Sync line will be pulse ran- 
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domly and the Read Byte Clocks will be reset 
randomly. 


C.5.3 Loopback Function 


When the Loopback Enable Line is brought posi- 
tive the loopback function is enabled. In this 
operating mode the serial data stream from the 
transmitter is routed to the input of the retiming 
latch. After the time required for bit and byte 
synchronizations this data will be available on 
the receive data output lines. During loopback 
the operation of the communications media is 
not defined. 


The loopback function is defined at the FC-1 
rather than the FC-O0 level. 


C.5.4 Signal Detect 


The Signal_ Detect line shall go positive when an 
incoming signal is detected. This line is the 
implementation of the 
FC-0 Signal Detect.Indication primitive of the 
FC-0O service interface. 
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Annex D. Cable plant usage (informative) 


This annex is not part of the standard but is 
included for information purposes only. 


The data links described in section 6 provide 
maximum optical power budgets. For planning 
purposes these data links will support the com- 
munication distances indicated in tables 5 and 6. 
Cable plant specification in section 8 defines the 
cable plant optical attenuation ranges for the 
data links. 


This section documents the assumptions leading 
to the nominal communications distances and 
describes the cable plant in terms of number of 
connectors and splices and assumed cable 
parameters. Operation within this combination of 
parameters will provide for operation at the 
nominal communications distance. Other combi- 
nations will support greater or lesser distances. 


D.1 Analysis method, loss limited 


Using a statistical approach, the system loss 
budget constraint requires that the loss budget 
exceed the mean loss of the cable plant by at 
least three standard deviations. 


Therefore: 
LB — yt, > 30, (E.1) 
Where: 
LB = Loss Budget 
Hy 
= Mean link loss 
oO; 
= Standard deviation of link loss 
The link losses are given by: 
Mi = le +Nstts + NoontHcon + Hel (E.2) 


and 


of = Iphoc + Nsos + NconIcon + Fer (E.3) 
Where: 
I, 
= Total length of the cable plant 
Ir 
= Average reel length of the cable 
He 
= Mean cable loss 
Oc 
= Standard deviation of cable loss 
Ns 
= Number of splices 
Hs 
= Mean splice loss 
Os 
= Standard deviation of splice loss 
Ncon 
= Number of connectors 
HCON 
= Mean connector loss 
OCON 
= Standard deviation of connector loss 
Mel 
= Mean excess coupling loss due to 
mode field mismatch in the cable plant 
Oc} 


Standard deviation of excess coupling 
loss 


A cable splice is assumes to be located at each 
end of the trunk and at one per Km over the 


1 This requirement is more stringent than the two sigma requirement found in TI.106, “American National Standard for 
Telecommunications Digital Hierarchy Optical Interface Specification: Single-Mode,” March 7,1988. This additional 
requirement is in anticipation of a more diverse, multivendor, cable which is more difficult to control over it’s life. 
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length of the trunk. In addition two splices are 
assumed for future repair and change activity. 
This results in an effective reel length of 1 Km. 
The number of splices in the link is given by: 


lt 
No = 342 


where Ns is an integer rounded upward. 


D.2 Analysis method, bandwidth 
limited 


For multimode fiber length estimates, the total 
distance limitation can be loss limited (see D.1 
above) or bandwidth limited. There are two 
cases for the bandwidth limitation: short wave- 
length laser datalinks and LED datalinks. 


For the short wavelength datalink, divide the 
cable manufacturer’s specified bandwidth, given 
in MHz*Km, by a constant factor of 0.8 to obtain 
the cable bandwidth in units of MBits/s*km. This 
0.8 factor is a net result of combining commonly 
accepted cable bandwidth to system baud rate 
conversion factor of 0.7 with the additional effect 
of chromatic dispersion present at the 780 nm 
wavelength region. Then divide this number by 
the data rate, given in MBits/s to determine the 
maximum cable plant distance. 


For the LED data link, an effective cable band- 
width is calculated from the modal bandwidth 
and chromatic dispersion (intramodal) contrib- 
utions. The length limit is then calculated from 
this effective cable bandwidth. 


The Effective System Bandwidth can be repres- 
ented by the relationship of intramodal and 
modal bandwidth of a given span as shown 
below: 


1 1 1 


ee ge ES ee en a (E.4) 

B Wertect B W modal B Wintra 

where: 

BW 

aaa = The bandwidth of a fiber limited by 
the pulse broadening due to optical 
power traveling via different wave- 
guide modes. This is the specified 
bandwidth of the cable. 

BW 


intra 


= The bandwidth of a fiber limited by 
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the pulse broadening due to chromatic 
dispersion (the speed of an optical 
pulse changes as its wavelength 
changes). 


The chromatic dispersion of a fiber can be calcu- 
lated by using the equation below: 


4 


So Ao 
D(A) = <P ]A-AE | Epsiinm-km)] 5) 


Where 
D(A) 
= Chromatic dispersion in ps/nm-km 
So 
= Dispersion function slope at Ap 
Ao 
= The zero dispersion wavelength 
A 


The wavelength of operation 


For LEDs operating near 1300 nm: 


BWintra = “gon [MHZ] (E.6) 
Cintra = La} D(A(AA 1? 4 SOA RI (E.7) 
Where: 
Cintra 
= RMS pulse broadening in ps 
k 
= 0.425 (the conversion factor from FWHM 
to RMS) 
AA 
= FWHM source spectral width in nm 
’ | 
= Length in km 
So 
= Dispersion slope in ps/(nm 
2¢km) 


a ee ee ee ee es —mee ET SE eo a TE AA EE _—e owe ——_ see 


D.3 Single mode cable plant usage 


For the single mode cable length estimates con- 
sider the data links of section 6.1, “SM data 
links.” The data links with a nominal distance 
capability of 10 Km have 14 dB loss budgets and 
the data links of with a nominal distance of 2 Km 
have 6 dB loss budgets. The connector at each 
end is accounted for in the interface power spec- 
ifications of section 6.1 and is not included in the 
cable plant. Two (2) dB has been removed from 
the difference between the transmitter output 
power and the receiver sensitivity specifications 
to account for reflection and dispersion power 
penalties. 


The cable parameters for the single mode loss 
budget are specified in table 60. 


Table 60. Single mode cable plant parame- 
ters 
FC-0 sym Value 
Parameter 


0,50 dB/Km 
0 dB/Km 


0,15 dB/spl 
0,10 dB/spl 


0,60 dB/con 
0,20 dB/con 


Additional 
coupling loss 


Substituting in Equations (E.2) and (E.3) gives: 


0,50/, + 0,15(3 + J,) + 0,6Ncon + 0,40 
0,65/, + 0,85 + 0,6Ncon 


HL 


and 


a? = Ipi(0)* + (3 +/,)(0,10)° + Neoy(0,20)" + (0) 
0,01), + 0,04Nooy + 0,03 


The maximum lengths estimated by iteratively 
solving Equation (E.1) found in table 61. 


FC-PH REV 2.1, May 25, 1991 


100-SM-LL-L 
50-SM-LL-L 
25-SM-LL-L 


D.4 Multi-mode cable plant usage 


The data link in section 6.3 provides a maximum 
optical power budgets of 12 dB for SW laser 
links and 6 dB for LW LED links. The connector 
at each end is accounted for in the interface 
power specifications and is not included in the 
cable plant. In SW laser or LED based systems, 
there are no additional loss to account for 
reflection and dispersion power penalties. For 
planning purposes the data link will support dis- 
tances shown in table 63 based on the assump- 
tion noted in table 6. Other combinations will 
support greater or lesser distances. 


The cable parameters for the multi-mode loss 
budget are specified in table 62. 


Table 62. Multi mode cable plant parame- 
ters 


FC-0 sym Value 
Parameter 
Cable Versions 
1) 50/125, A=780nm vj 4,0 dB/Km 
2) 62,5/125, A=780nm cf 4,5 dB/Km 
3) 50/125 and 62,5/125 7] 1,5 dB/Km 
A=1 300nm 02 


0 dB/Km 


0,15 dB/spl 
0,10 dB/spl 


8] 
c3 
oO 
c 
LU 
S$ 
Of 
Ss 
: 


Additional 
coupling loss 


0,5 dB/con 
0,2 dB/con 


con 
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The maximum lengths estimated by iteratively 
solving equation (E.1) are: 


Table 63. Calculated max. multi-mode 
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. This length limit of 1,0 Km is due to fibre 


bandwidth constraints (see table 20), the 
length limit due to loss budget (LB) would be 
2,0 Km. 


. This length limit of 350 m is due to fibre 


bandwidth constraints (see table 17), the 
length limit due to loss budget (LB) would be 
1,8 Km. | 


. This length limit of 700 m is due to fibre 


bandwidth constraints (see table 17), the 
length limit due to loss budget (LB) would be 
1,8 Km. 


. This length limit of 1,0 Km is due to fibre 


bandwidth constraints (see table 17), the 
length limit due to loss budget (LB) would be 
1,4 Km. 


. For these cases the distance must be deter- 


mined on a case by case basis. 
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Annex E. Coaxial cable examples (informative) 


| This annex is not part of the standard but is included for information purposes only. 


E.1 Example of CATV coax cable characteristics 


Table 64. Typical characteristics of 75 Q, 0,27” O.D. CATV coax (e.g.: RG-6/U) 


Category Impedance Capacitance Attenuation Velocity 
| Electrical 75+5 O 17 pF/ft nom. 11dB/50m 82% 
| @531MHz 


Category Material Wall thickness Dielectric Constant Outer diameter 


Insulation Foamed 1,77 mm nom. 1,50 nom. 4,57 mm nom. 
polyethylene 


Category Material Coverage Outer diameter 
Shield Tin plated Cu braid 100% min. 5.84 mm nom. 
over foil 


| E.2 Example of plenum rated coaxial cable characteristics 


Table 65. Typical plenum rated coaxial cable characteristics (e.g.: RG-6/U) 


Category Impedance Capacitance Attenuation Velocity 
Electrical 75+5 Q 16,5 pF/ft nom. 11dB/50m 82% 
@531MHz 


Category Material Size Construction Outer diameter 
Conductor Bare copper AWG 18 Solid 1,01 mm nom. 
covered steel 


Category Material Coverage Outer diameter 
Shield Tin plated Cu braid 100% min. 5,59 mm nom. 
over foil 
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E.3 Example of miniature coax cable characteristics 


Table 66. Typical characteristics of 75 (2, miniature coax (e.g.: RG-179 B/U) 


Category 
Electrical 


Impedance 
75+5 Q 


Material 

Silver coated 
copper covered 
steel 


Category 
Conductor 


Material 
Extruded TFE 
Teflon 


Category 
Insulation 


Category Material 
Shield Silver coated 
Cu braid 


Capacitance 
20 pF/ft nom. 


Wall thickness 
0,635 mm 


Attenuation 


7dB/10m 


@531MHz 


Construction 
7-38 stranded 


Dielectric 
Constant 
2,10 nom. 


Coverage 
95% min 


Velocity 
70% 


Outer diameter 
0,305 mm nom. 


Outer diameter 
1,60 mm nom. 


Outer diameter 
2,11 mm nom. 


E.4 Example of double-shielded miniature cable characteristcs 


Table 67. Typical characteristics of 75 QO, double-shielded miniature coax (e.g.: miniature RG-59) 


Category 
Electrical 


Impedance 
75+5 O 


Material 
Copper covered 
steel 


Category 
Conductor 


Material 
Foamed 
polyethelene — 


Category Material 
Shield #1 Bonded Alum. Tape 
Category Material 

Aluminum braid 


Category 
Insulation 


Shield #2 


Category Material 
Jacket PVC 
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Capacitance 
17 pF/ft nom. 


Wall thickness 


0,711 mm 


Attenuation 


7dB/10m 


@531MHz 


Construction 


Solid 


Dielectric 
Constant 
1,50 nom. 


Coverage 
96% min 


Coverage 
60% min 


Velocity 
18% 


Outer diameter 
0,508 mm nom. 


Outer diameter 
1,90 mm nom. 


Outer diameter 
2,09 mm nom. 


Outer diameter 
2,00 mm nom. 
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Annex F. Preferred connector requirements (informative) 


This annex is not part of the standard but is 
included for information purposes only. 


Application usage; machine interface only 
(FCS compliant connector on Printed Circuit, 
Patch Panel or Bulk Head encouraged but 
not required) 


Single connector design for Multi-mode and 
Single mode 


Single channel (2-fiber) granularity 


Push/pull insertion/withdrawal 
Audible/tactile insertion feedback 
Low insertion/withdrawal force 


Easy ferrule access for inspection § and 
cleaning 


The Single mode FCS receptacle and associ- 
ated Single mode connector plug will have to 
be unique and different from the Multimode 


receptacle/connector plug design to insure 
the Multimode connector plug cannot be 
engaged in a Singlemode receptacle. This is 
required for LASER Safety Compliance. 


Duplex & polarized 


Keyed to prevent cross plugging 


Color differentiation 
singlemode) 


Table 68. Preferred connector characteristics 
FERRULE CHARACTERISTICS MULTI-MODE SINGLE MODE 
50/125 im 9/125 um 
62,5/125 pm 


FUNCTIONAL/OPERATIONAL 


(multi-mode / 


< 0,3 dB 
Connector optical cross plug repeatability (2) < 1,0 dB 
Return loss (fibre-fibre) 26 dB min 


MECHANICAL CHARACTERISTICS 


Axial pull force (3) 90 N (20 Ibs) 90 N (20 Ibs) 
Low insertion/withdrawal force 20 N (4,5 Ibs) 20 N (4,5 Ibs) 
Cable/connector axial pull strength (min)(4) 140N (30 Ibs) 140N (30 Ibs) 
Resistance to off axis pull 


CONNECTOR SIZE 


Ferrule to ferrule spacing (maximum) 12.7mm (0,5”) 12.7 mm (0,57) 
Lateral connector pitch (maximum) 25mm (0,98”) 25mm (0,98”) 
Low profile component height (maximum) 12mm (0,47”) 12mm (0,47”) 


ENVIRONMENTAL 


Operating temperature range 0 to 60°C 0to 60°C 
Relative humidity range 5 to 95% RH 5 to 95% RH 
Storage/shipping temperature -40 to 85°C -40 to 85°C 
5 to 100% RH 5 to 100% RH 


Connector optical repeatability (1) 


Storage/shipping relative humidity 
Cable flammability (5) 
Connector assembly flammability (5) 


RELIABILITY 


Insertion/withdrawals 250 min 250 min 
Product life (minimum) 100K hours 100K hours 


NOTES - 
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1. 
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Connector optical repeatability: is the fibre- 
to-fibre optical loss repeatability encountered 
with multiple insertions in the same mating 
connector pair. 


. Connector optical cross plug repeatability: is 


the fibre-to-fibre optical loss between any 
two ANSI FCS compliant connectors. 


. Axial pull force on the cable & connector 


latched in its mating receptacle: is the 


. Cable/connector axial pull force: 


receptacle-to-connector minimum retention 
force. 


is the 
minimum connector-to-cable retention force 
(measure of cable strain relief strength). 


. All applicable safety codes: are to apply and 


are dependent on application/facility usage. 
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Annex G. FC-0 Service interface (informative) 


This annex is not part of the standard but is 
included for information purposes only. 


This annex defines the interfaces of the commu- 
nications media controls and services that are 
valid for all FC-O data links. The controls and 
services are described in terms of logical primi- 
tives rather than physical signals to allow for the 
widest range of physical implementations. 


The interface between FC-0 and FC-1 is inten- 
tionally structured to be technology and imple- 
mentation transparent. That is, the same set of 
commands and services may be used for all 
signal sources and communications media. The 
intent is to allow for the the interface hardware 
to be interchangeable at the system level 
without regard to the technology of a particular 
implementation. As a result of this, all safety or 
other operational considerations which may be 
required for a specific communications technolgy 
are to be handled by the FC-O level associated 
with that technology. Such safety features are 
provided by by the Link Control block of 
Figure 76. 


G.1 General Description 


As an aid in visualizing the FC-O services refer 


to Figure 76. In this figure the general function | 


nerformed by the FC-O level are illustrated along 
with the logical control associated with the func- 
tions. This diagram is meant to represent the 
most complex implementation of the FC-O level. 
In some cases individual implementation, or 
some types of media, may not require all of 
these function or logical communications. 

For example, LED implementations will not 
require the FC-0 Signal Detect to be communi- 
cated to the link control function. In the case of 
a SAW filter type of clock recovery the 
FC-O0 Resync and the FC-0_Clock_Reference will 
not be required. The basic function of the primi- 
tive controls and services are: 


FC-0 Data.Request 
The serial data to be transmitted over 
the communications media. 


FC-0_Data.Indication 
The retimed serial data stream 
received from the communications 
media. 


FC-0_ Transmit 
The command to turn the transmitter 
on and Off. 


FC-0_ Transmit_State 
The present internal state of the 
transmitter. 


FC-0_Signal_Detect 
An indication of the presence or 
absence of a signal on the communi- 
cations media. 


FC-0 Clock_Out 
The timing clock recovered from the 
incoming data. 


FC-0 Clock_Reference 
A frequency reference to be used as 


an aid in acquiring bit 
synchronisation. 

FC-0 Resync 
A command from the FC-1 level to 
attempt to reacquire bit 


synchronisation. 


G.2 FC-0 States 


G.2.1 Transmitter States 


The transmitter is controlled by the FC-1 level. 
Its function is to convert the serial data received 
from the FC-1 level into the proper signal types 
associated with the operating media. 


— Transmitter Not-Enabled State: A not- 
enabled state is defined as the optical output 
off for optical communication media and a 
logical zero for coaxial media. This is the 
state of the transmitter at the completion of 
power on sequence unless the transmitter is 
specifically directed otherwise by the FC-1 
level. 


— Transmitter Enabled State: The transmitter 
shall be deemed to be in an enabled state 
when the transmitter is capable of operation 
within its specifications while sending valid 
data patterns. 
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FC-0 Data. request 


FC-0 Transmit 
FC-0 Trasmit State 


FC-0 Signal Detect 
FC-@ Data. indication 


FC-0 Clock Out 


— Transition Between Not-Enabled and Enabled 
States: The sequence of events required for 
the transition between the not-enabled and 
enabled states will be media dependant, 
both as to the time period required and the 
optical or logical activity on the media inter- 
face. 


— Transmitter Failure State: Some types of 
transmitters are capable of monitoring them- 
selves for internal failures. Examples are 
laser transmitters where the monitor diode 
current is may be compared against a refer- 
ence to determine proper operating point. 
Other transmitters, such as Light Emitting 
Diodes and coaxial transmitters do not typi- 
cally have this capability. If the transmitter 
is capable of performing this monitoring 
function then a detection of a failure shall 
cause entry into the failure state. 


G.2.2 Receiver States 


The function of the receiver interface is to 
convert the incoming data from the form 
required by the communications media 
employed, retime the data, and present the data 
and an associated clock to the FC-1 level. 


The receiver has no states. 
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Figure 76. FC-0 logical structure 
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G.3 FC-1 Services 


Figure 77 graphically portrays the Open Systems 
Interface (OSI) model as applied to the FC-0 
service interface. 


FC-1 FC-6 FC-1 FC-8 
initiated initiated initiated initiated 
function function function function 
FC-1 | 


FC-1 


Service User 


a 9 


Service Interface 


‘ 
rn 8 CA 8 He 
32a waa | 
ovwvrsd@gcedpds" 0 


o 
a 
® 
t 
t 
' 
' 
t 
‘ 
4 
1 
' 
a 
& 
2a wes Of 
orex3srsea6eocees no WwW 
3s OU er OM Os 
1 


Service Provider 


ae eee aera eee eae rece 


Figure 77. FC-0 service interface 


Primitives are of four generic types: 


Request The request primitive is passed from 
the FC-1 level to the FC-0 level to 


request that a service be initiated. 


Indication The indication primitive is passed 
from the FC-0 level to the FC-1 level 
to indicate an internal FC-0 event 


which is significant to the FC-1 level. 
This event may be logically related to 
a remote service request, or may be 
caused by an event internal to the 
FC-0 level. 


Response The response primitive is passed 
from the FC-1 level to the FC-O level 
to complete a procedure previously 
invoked by an indication primitive. 


Confirm The confirm primitive is passed from 
the FC-0 level to the FC-1 level to 
convey the results of one or more 
associated previous service 


request(s). 


Figure 78 illustrates the primitive combinations 
that are supported by the FC-O service interface. 
Each primitive described is this section if the 
standard is correlated to one of the subfigures 
(a), (b), (c), or (d) of Figure 78. This figure also 
indicates the logical relationships of the primi- 
tive types. Primitive types that occur earlier in 
time and are connected by dotted lines in the 
diagrams are the logical antecedents of subse- 
quent primitive types. 


(a) (b) 


Request 
——>}\ 
\ Indication 
\ a 
\ | Indication 
\|---s > 
(c) (d) 
Request 
-— 
Request 
Pee 
Confirm 
——_—_—_—_—_— 


Figure 78. FC-0 Service Interface Primitive Com- 
binations 


The following service primitives are defined by 
the FC-0 service interface: 
— FC-0 Transmit 

— request 


— FC-0_Transmit_State 
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— indication 
— FC-0 Data 
— request 
— Indication 
— FC-0 Clock_Out 
— indication 
— FC-0 Clock_Reference 
— request 
— FC-0 Resync 
— request 
— FC-0 Signal Detect 


— jndication 


G.4 FC-0 transmit 


G.4.1 FC-0_transmit.request 


G.4.1.1 Function 


This primitive is used by the FC-1 level to control 
the operational state of the FC-O transmitter. 


G.4.1.2 Semantics 


The FC-0 transmit.request service primitive is 
defined as follows: 


FC-0 transmit.request(state) 


state The requested state of the FC-O trans- 
mitter. The allowable states of this 
parameter are enable, and disable. 
The format of this parameter is not 
defined by the standard. 


G.4.1.3 When Generated 


The FC-1 level issues the FC-0_transmit.request 
with state = enable to request that the trans- 
mitter begins its transition to an enabled state. 
During this time the FC-1 level must be sup- 
plying valid encoded information to the FC-0 
level via the FC-O0_data.request primitive. 


The FC-1 level issues the FC-0_transmit.request 


with state = disable to request that the trans- 
mitter begin a transition to a not-enabled state. 
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G.4.1.4 Effect on Receipt 


The receipt of this primitive with state = enable 
causes the FC-0 level to attempt to go to the 
enabled state. If the FC-O level is in the Not- 
Enabled State the Transition state is entered. If 
the FC-0O level is in the Transition State the state 
is not affected. If the FC-0 level is in the Failure 
State no action is taken. 


The receipt of this primitive with state = disable 
causes the FC-0 level to go to the not-enabled 
state from all states except the failure state. If 
the FC-0 level is in the failure state no action is 
taken. 


G.4.1.5 Additional Comments 


It is anticipated that for FC-O media that do not 
have safety requirements the transition state will 
be a null state. For these cases the FC-0 level 
will go directly from the Not-Enabled state to the 
Enabled State. 


When this primitive is issued with state =enable 
the FC-1 level must issue FC-0 data.request 
primitives continuously untill this primitive is 
again issued with state =disable. 


This primitive is illustrated by Figure 78 (qd). 


G5 FC-0_transmit_state 


G.5.1 FC-0_transmit_state.indication 


G.5.1.1 Function 


This primitive is used by the FC-0 level to indi- 
cate to the FC-1 level that the transmitter is 
active and capable of transmitting data on the 
media interface. 


G.5.1.2 Semantics 


The FC-0_transmit_state.indication service primi- 
tive is defines as follows: 


FC-0_ transmit_state.indication(status) 


The state of the FC-0 transmitter. The 
allowable states of this parameter are 
active, inactive, and fault. The format 
of this parameter is not defined by 
the standard. 


status 
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G.5.1.3 When Generated 


The FC-0 level issues the 
FC-0 transmit_state.indication primitive = with 
status = active continuously while the trans- 


mitter is in the enabled state and is capable of 
transmitting data on the media interface. 


The FC-O level issues the 
FC-0_transmit_state.indication primitive with 
status=fault when the transmitter is in an 
internal fault state as determimed by any 
internal fault monitoring which it may possess. If 
the transmitter contains no_ internal fault 
detection circuits this is a null state. 


The FC-0O level issues the 
FC-0 transmit_state.indication primitive with 
status = inactive continuously when the trans- 


mitter is not in the enabled or failure states. This 
will occur when the transmitter is in any of the 
following states: 


— Transmitter not-enabled;: 


— Transmitter in transition between enabled 
and not-enabled states in either direction; or 


— Transmitter not operational due to an 
internal fault which is not detected by 
internal fault monitoring circuitry. 


G.5.1.4 Effect on Receipt 


Upon receipt of this primitive with the status = 
active the FC-1 level may assume that any 
issued FC-0 data.request primitives will be 
placed on the communications media. 


Upon receipt of this primitive with the status = 
inactive the FC-1 level will be informed that the 
response of the FC-O level to any 
FC-0 data.request primitives is undefined. 

Upon receipt of this primitive with the status = 
fault the FC-1 level will be informed that a repair 
activity is required. 

G.5.1.5 Additional Comments 

This primitive is illustrated by Figure 78 (b). 


G.6 FC-0 data 


G.6.1 FC-0_data.request 


G.6.1.1 Function 


This primitive is used by the FC-1 level to pass 
transmission requests to an associated FC-0 
level. 


G.6.1.2 Semantics 


The FC-O data.request service primitive is 
defined as follows: 

FC-0 data.request(bit) 
bit The information which is to be trans- 


mitted on the media. The allowable 
values of this parameter are one and 
zero. 


G.6.1.3 When Generated 


This primitive is generated by the FC-1 level. It is 
the serialized form of the data to be transmitted 
as formatted and coded by the FC-1 level. 


G.6.1.4 Effect on Receipt 


Upon receipt of this primitive the FC-0O level will 
change the communications media to the state 
appropriate to the parameter value, provided the 
FC-0 tramsmitter is in the enabled state as indi- 
cated by the FC-0_transmit_state.indication prim- 
itive with status = active. The response to this 
parameter will be undefined if the FC-O level is 
not in the enabled state as indicated by the 
FC-0 transmit_state.indication primitive with 
status = active. 


bit = one shall be represented by a optical high 
power state in the case of optical media and a 
logical one in the case of coaxial media. bit = 
zero shall be represented by an optical low 
power state in the case of optical media and a 
logical zero in the case of coaxial media. 


G.6.1.5 Additional Comments 


This primitive shall be presented at a rate appro- 
priate to the media in use. It must be presented 
continuously when FC-1 level has requested the 
transmitter to be in the enabled state by issuing 
the FC-0 transmit.request primitive — with 
state=enable. Issuing of this. primitive is 
optional when the FC-0 transmit.request primi- 
tive has been issued with state =disable. 
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This primitive is illustrated by the Request 
portion of Figure 78 (a). 


G.6.2 FC-0_data.indication 


G.6.2.1 Function 


This primitive is used by the FC-0 level to pass 
data received from the media to the associated 
FC-1 level. 


G.6.2.2 Semantics 


The FC-0 data.indication service primitive is 
defined as follows: 


FC-0 data.indication(bit) 


bit The information which was received 
from the media. The allowable values 
of this parameter are one and zero. 


G.6.2.3 When Generated 


This primitive is generated synchronously with 
the FC-O0 clock_out primitive. When the 
FC-O0 clock_out.indication is issued the FC-1 level 
may receive the FC-0_ data.indication primitive. 
When the FC-0 clock_out.indication is not 
present the value of the FC-0_data.indication is 
not guaranteed and the FC-1 level is advised to 
not receive the FC-0 data.indication primitive. 


The parameter value of bit = one is generated 
by a high level of optical power in the case of 
optical media or a logical one in the case of 
coaxial media. 


The parameter value of bit = zero is generated 
by a low level of optical power in the case of an 
optical media or a logical zero in the case of 
coaxial media. 


G.6.2.4 Effect on Receipt 
The receipt of an FC-0O data.indication primitive 
by the FC-1 level allows the FC-1 level to receive 


data. 


G.6.2.5 Additional Comments 


In the event that there is no input to the FC-0 
from the media this output is undefined. 


This primitive is illustrated by the Indication 
portion of Figure 78 (a). 
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G.7 FC-0 clock_out 


G.7.1 FC-0_clock_out.indication 


G.7.1.1 Function 


This primitive is used by the FC-0O level to 
provide synchronisation information for the 
FC-0_data.indication to the FC-1 level. 


G.7.1.2 Semantics 


The FC-0_clock_out.indication service primitive is 
defined as follows: 


FC-0_clock_out.indication 


No parameters are defined for this primitive. 


G.7.1.3 When Generated 


An FC-0 level issues the 
FC-0 clock_out.indication primitive to provide a 
data transmission synchronisation signal to the 
FC-1 level. When this primitive is issued the 
FC-0 data.indication primitive will be in a valid 
state. At this time the FC-1 level may choose to 
receive FC-0 data.indication. At times between 
issuing the FC-0O_clock_out.indication the 
FC-0_data.indication may not be in a valid state 
and it is recommended that the FC-1 level not 


receive the FC-0O data.indication primitive at - 


these times. 


G.7.1.4 Effect on Receipt 
Receipt of this primitive may be used by the 


FC-1 level to synchronize data transmission 
between the FC-0 and FC-1 levels. 


G.7.1.5 Additional Comments 
In the event that there is no input to the FC-0O 
from the media the output frequency and timing 


information is undefined. 


This primitive is illustrated by Figure 78 (b). 


G.8 FC-0_Clock_Reference 


G.8.1 FC-0_clock_reference.request 
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G.8.1.1 Function 


This primitive is issued by the FC-1 level as a 
aid in initializing the clock recovery functions of 
the FC-0 level. 


G.8.1.2 Semantics 


The FC-0_clock_reference.indication service 


primitive is defined as follows: 
FC-O_clock_reference.indication(boundary) 


boundary An_ indication of the transmission 
intervals of the reference clock. The 
allowable values of boundary are 
word and null. 


G.8.1.3 When Generated | 


The FC-1 level issues this primitive with value 


boundary = word to indicate the reference 
times of the clock signal. This primitive has a 
value of boundary = null at intervals between 


these reference times. The FC-1 level must 
issue this primitive with boundary = word con- 
tinuously at a rate appropriate to the physical 
implementation. 


G.8.1.4 Effect on Receipt 


This primitive is used in the FC-0_ bit 
synchronisation to initialize the clock recovery to 
near the bit frequency if a phase lock loop (PLL) 
form of clock recovery is used. 


G.8.1.5 Additional Comments 


In the event that the FC-O implements the clock 
recovery using a method (ex. SAW filters) which 
does not require a frequency reference this 
primitive will not be required. 


This primitive ts illustrated by Figure 78 (d). 


G.9 FC-0_signal_detect (optional) 


G.9.1 FC-0_signal_detect.indication 


G.9.1.1 Function 


This primitive is issued by the FC-0O level to 
inform the FC-1 level of the presence or absence 
of a signal on the communications media. 


to aan Bp Cae 


G.9.1.2 Semantics 


The FC-0 signal _detect.indication service primi- 
tive is defined as follows: 


FC-O signal detect.indication(state) 


state The result of the signal detect circuit. 
The allowable values of this param- 


eter are present and absent. 


G.9.1.3 When Generated 


The FC-0 signal _detect.indication will have state 
= present when the receiver has determined 
that the signal on the input is above a predeter- 
mined level. In the case of optical media the 
activation level will lie in a range whose upper 
bound is the minimum specified sensitivity of the 
receiver and whose lower bound is the lower of 
either the point where the bit error rate will 
exceed 10-2 or 7 dB below the minimum receiver 
sensitivity. If the signal is below this range the 
primitive will be issued with state = absent. 


Implementation of a signal detect function is 
optional. In the event that signal detect is not 
implemented the FC-O shall issue this primitive 
with state = present. 


While there is no defined hysteresis for this 
primitive the primitive shall undergo a single 
transition between the values of the state param- 
eter for any monotonic increase or decrease in 
the optical power. The optical power at the tran- 
sition points shall lie within the’ previously 
defined bounds. 


For optical links that employ a link control func- 
tion, such as section Annex H, then this “Signal 
Detect” is replaced by the ”Link Status” signal, 
because it provides the service primitive 
described in this section. 


In the case of optical media the reaction time of 
this primitive to a change in the input optical 
power shall be less than 12 seconds. 


In the case of coaxial media this primitive shall 
be issued with state = absent within 12 seconds 
of the occurence of the fault. Otherwise 
State = Present will be issued. | 


FC-PH REV 2.1, May 25, 1991 


G.9.1.4 Effect on Receipt 


The FC-1 level uses this primitive to determine if 
a receiver which has been in a_ loss-of- 
synchronisation state for more than one second 
should enter the loss-of-synchronisation-failure 
state or the loss-of-signal-failure state. 


G.9.1.5 Additional Comments 


This primitive is illustrated by Figure 78 (b). 


G.10 FC-0 resync 


G.10.1 FC-0_resync.request 


G.10.1.1 Function 


This primitive is used by the FC-1 level to 
request that the FC-O attempt to acquire bit 
synchronisation. 


Some bit synchronisation methods do _ not 
require an initialization procedure. In the event 
that one of these methods is employed by the 
FC-0 level this primitive is not required. 


G.10.1.2 Semantics 


The FC-O_resync.request service primitive is 
defined as follows: 


FC-0 resync.request 


No parameters are defined for the 
FC-0_resync.request primitive. 


G.10.1.3 When Generated 


This primitive is issued by the FC-1 level to 
request that the FC-0 level attempt to acquire bit 
synchronisation. This may occur as a result of 
an FC-1 reset condition. 


G.10.1.4 Effect on Receipt 


When this primitive is received the FC-0O level 
will begin any bit synchronisation procedure 
appropriate to the specific implementation. The 
method of acquiring bit synchronisation is not a 
subject of this standard. 


The synchronisation procedure shall take less 


than 1 millisecond from the receipt of this primi- 
tive. 
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G.10.1.5 Additional Comments | 

The time required to achieve bit synchronisation 
is highly variable depending on the particular bit 
synchronisation method employed. 


This primitive is illustrated by Figure 78 (qd). 
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Annex H. The open fibre control interface (informative) 


This annex is not part of the standard but is 
included for information purposes only. 


The Open Fibre Control (OFC) safety interlock 
system was introduced in section 6.2.3, ”“The 
open fibre control safety system”; in addition, the 
four-state state machine and handshake timings 
required for compatibility were specified. The 
details of a recommended implementation of this 
OFC system are described in the first part of this 
annex. Much of the information presented in 
section 6.2.3 is repeated here for purposes of 
completeness. The second part of this annex 
presents a justification of the maximum power 
values and OFC timing values specified for the 
system. 


H.1 OFC Interface Description 


H.1.1 System overview 


The OFC system functions as a safety interlock 
by detecting whenever the data link is disrupted 
(i.e. cut fibre or disconnected connector) and 
forcing the transceiver into a repetitive pulsing 
mode of operation with very low duty cycle. The 
link can return to normal data traffic only after 
the OFC system detects that the link has been 
repaired and the proper reconnection handshake 
has taken place between the two transceivers in 
the link. 


H.1.1.1 Input lines 


Input lines to the OFC system consist of a 
system clock and two independent loss-of-light 
(LOL) detector lines that indicate whether-or-not 
an optical signal is being received by the 
photodetector/receiver. At least one of the two 
LOL detectors is AC coupled to the 
photodetector/receiver and therefore sensitive 
only to modulated optical signals (see figure 21 
in section 6.2.3). 


H.1.1.2 Output lines 


The output lines consist of two laser driver 
control lines and an optional link status line. 
The two laser driver control lines are of opposite 
polarity to prevent voltage control problems from 
accidentally activating the laser. They are also 
each independently capable of disabling the 
laser drive circuitry (via separate control paths). 
The link status line is used to signal the user 
system when the link is inactive due to a loss-of- 
light condition detected by the OFC system. 


H.1.1.3 Additional control lines 


In addition to the input and output lines, there is 
a power-on-reset line and two optional user 
system control lines that interface with the OFC 
system. The power-on-reset line is used to syn- 
chronize the counters and state machines in the 
system. The two user system control lines, link 
control and loop-back enable, interact with the 
OFC system by forcing the OFC to disable the 
laser drive circuitry and turn off the laser. Once 
the laser is turned off, only the OFC system can 
turn it back on by performing a link reconnection 
handshake. 


H.1.1.4 Reconnection handshake timings 


The repetitive pulsing and reconnection hand- 
shake are controlled by logic in two _ state 
machines contained in the OFC system. The two 
state machines are independent and identical. 
This redundancy found throughout the OFC 
system is required by the safety standards which 
State that the safety interlock system must 
remain functional during single fault conditions. 


The OFC timings used during a reconnection 
attempt depend upon the maximum (worst case) 
power accessible from a transmitter receptacle 
port, the circuit components and technology, and 
the restrictions imposed by the laser safety 
standards. The timings chosen for this standard 
are used for both the 531 Mbit/s and 266 Mbit/s 
SW laser data links, however, they are based on 
the maximum launched power for the 531 Mbit/s 
link since it is larger than the 266 Mbit/s link. 
The following power and timing specifications 
were given in section 6.2.3: 


1. Transmitter receptacle power 
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— maximum (worst case) = 2,3 dBm (1,7_ 


mW) 
2. Pulse repetition time, T, (Disconnect state) 
— maximum = 11,9 sec 
— minimum = 11,7 sec 


3. Pulse duration, D1=D3=t, (Disconnect and 
Reconnect states) 


— maximum = 410 microsec 


— minimum = 400 microsec 


+LOSS OF 
CIGNAL DIGITAL 
(DETECTOR 1) 


-POR DE- ——pE-GLITCH| 
-~LOOP-BACK 
hang ano DE-GLITC 


CONTROL 


SYSTEM 
CLOCK CLOCK GEN GEN 


+LOSS OF 
CICNAL PITA O 


(DETECTOR 2) 


| 4. D2 stop time (Stop state) 
| — maximum = 1 260 microsec 


| — minimum = 1 250 microsec 


H.1.2 Block Diagram description of the 
OFC System 


A block diagram of a module that implements 
the OFC system control is shown in Figure 79. 
The discussion which follows explains the func- 
tion of each of the blocks. 


+ACTIVE STATE 


+LASER 
OFF 
4 TATE 


S 
4 MACHINE! 


STATUS 
+ACTIVE STATE 


OFC MODULE BLOCK DIAGRAM 


Figure 79. Possible implementation of the OFC system 


The OFC module provides two control paths that 
must be satisfied before the laser can be acti- 
vated. This provides the redundancy required by 
the laser safety standards. Each path has a 
digital filter, state machine and a counter. The 
internal redundancy is complemented externally, 
by two loss-of-light detectors and two control 
paths in the laser drive circuitry. 


The two loss-of-light detectors each feed a 
digital filter, the output of each filter is 
‘OR/EQUAL’d to form an internal Loss-of-Light 
(LOL) signal. The two filter outputs must be 
‘EQUAL’ during the Disconnect, Stop and Recon- 
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nect states to activate the laser and bring the 
link up to a normal operating mode. But once 
the system is in the Active state, the ‘OR’ is 
implemented so that only one light detector is 
required to bring the link down and deactivate 
the laser. 


The digital filters integrate the incoming signals 
to improve their reliability. The filters sample at 
a faster rate when acquiring a light present 
signal and at a slower rate when dropping a 
light present signal (i.e. setting LOL high), while 
still maintaining the correct handshake timings. 


The internal LOL signals are used to synchro- 
nize the counters and state machines. The state 
machines control the handshake algorithm 
implemented in the OFC system. Each state 
machine controls a ‘Laser Off output that con- 
nects to separate laser drive control circuits. 
The counters control the pulse repetition, pulse 
duration and stop times. The counters also 
provide the low frequency sampling clock to the 
digital filters. 


The OFC module contains a ring oscillator. The 
ring oscillator drives a clock detector that moni- 
tors the ‘System Clock’ coming into the module. 
If the ‘System Clock’ gets stuck high or low the 
clock detector will cause the laser to be deacti- 
vated. This provides a back up safety feature to 
the single clock coming into the module. The 
‘System Clock’ only has to slow down sufficiently 
for the clock detector to detect a fault. If the 
‘System Clock’ speeds up, all of the timings 
scale proportionately so that the ratio of the 
pulse duration time to the pulse repetition time 
remains constant. 


The response of the module to the external 
control signals, -Loop Back Enable, +Link 
Control and -POR, must not cause a pulse to be 
emitted when they are toggled. The logic must 
ensure that a safe time period exists between 
pulses. Hence any disruption of the OFC system 
must cause the state machine to be reset to the 
Disconnect state. 


H.1.3 The OFC State Machine 


The OFC state machine is the heart of the 
control system since it contains the logic that 
detects when the optical link becomes open due 
to a disconnection or break in the fibre and pre- 
sides over the link reconnection handshake 
when it detects that the link is once again 
closed. A state diagram of the algorithm imple- 
mented in the OFC system is shown in 
Figure 80. A description of all the states and 
transitions follows. 


The state machine has five variables that control 
the transitions from state to state. Loss of Light 
(LOL) is the “EQUAL” of the two light detector 
lines during the disconnect state, stop state and 
reconnect state, and the “OR” of the two light 
detector lines in the active state. In other words, 
both light detectors must agree to activate the 
link, but once activated either light detector 
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sensing no light will cause the state machine 
and optical link back to return to the disconnect 
state. The “master of link reconnection” (MAS) 
flag is used to insure that if a_ transceiver 
responds to receiving an incoming light pulse 
while in the disconnect state, then it can only 
respond to receiving a light pulse in the recon- 
nect state and it cannot initiate a reconnect state 
light pulse on its own. This prevents problems 
that could arise from timer variations and link 
synchronization. The three decodes are gener- 
ated by the system clock and counter in the OFC 
system. The decodes are used to ensure that no 
ON-OFF-ON sequence generated by the physical 
insertion of a fibre into the connector can acci- 
dentally satisfy the safety algorithm. 


The following list describes each of the four 
states of operation of the OFC system (refer to 
Figure 80 as needed): 


1. Disconnect state: 


While in the disconnect state the OFC 
system on each shortwave laser transceiver 
is operating the laser at a very low duty 
cycle to conform to laser safety emission 
limits. It activates the laser driver circuitry 
for 405 usec every 11,8 sec to check for a 
closed optical link between itself and the 
transceiver at the other end of the link. As 
long as the LOL flag remains high, the OFC 
system keeps the transceiver in this state. 
To exit from the disconnect state, light must 
be both sent and_ received by the 
transceiver. This condition can be satisfied 
in two ways: 


A. When the 11,8 sec timer expires, decode 
D1 is set high (D1=1), the MAS flag its 
set high (MAS =1), and the laser is acti- 
vated for the duration of the decode 1 
period (405 usec). If during this decode 
period an optical signal is received from 
the transceiver at the other end of the 
link (i.e. LOL=0O), then the OFC system 
proceeds to the stop state for the 
remainder of the decode 1 period. The 
MAS flag set high implies that this 
transceiver unit initiated the link recon- 
nection check by sending light first and 
receiving light second; it is considered 
the “master” of the link reconnection. 


B. If an optical signal is received (LOL=0O) 
sometime during the 11,8 sec. wait 
period, then the counters controlling the 
timing are reset, decode D1 is set high 
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(D1=1), the MAS flag is set low 
(MAS =0), and the laser is activated for 
the duration of the decode 1 period (405 
usec). This also causes the OFC system 
to exit to the stop state. The MAS flag 
set low implies that this transceiver unit 
is responding to a link reconnection 
attempt from the unit at the other end of 
the link. By receiving light first and 
sending light second, it is considered the 
“slave” of the link reconnection attempt. 


2. Stop state: 


In the stop state the OFC system forces the 
laser off. However, the laser is not disabled 
until after the decode 1 (D1) time period is 


LOL=1+D1=0 


DISCONNECT 
STATE 


(set/reset 
MAS flag) 


D2=1eL0L=1 


D1i=1 
+ 
LOL=0 
+ 
D2=1¢eLOL=0 


DEFINITIONS: 
LOL = Loss of light flag 


MAS = Master of link reconnection flag 
Dl = Decode 1 - ist time period flag 
D2 = Decode 2 - 2nd time period flag 
D3 = Decode 3 - 3rd time period flag 
(note: usec means microseconds) 


D2=0eD3=0 


complete. This ensures that both lasers are 
on long enough to satisfy the disconnect 
state exit condition at each transceiver unit. 
When the decode 1 time period ends, D1 is 
reset low (D1=0), D2 is set high (D2=1) and 
the laser driver circuitry is disabled for the 
duration of the decode 2 time period (1255 
usec). The OFC system remains in the stop 
state for as long as light is received (i.e. 
LOL=0); this could be for an_ indefinite 
period of time. There are two exit paths 
from the stop state: | 


A. One exit from the stop state is to con- 
tinue on to the reconnect state. This 
occurs when light is no longer received 


ACTIVE 


STATE 


RECONNECT 


STATE 
(action set 
by MAS flag) 


D2=1 + 
D3=1eLOL=1 


( 405 usec) 


= Link check 
(1255 usec) = Disable laser 
( 405 usec) = Link check 


Figure 80. Open Fibre Control module State Diagram 
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(LOL=1) and the decode 2 time period 
has not expired (D2=1). This is the 
normal chain of events during a recon- 
nect handshake. 


B. The other exit from the stop state takes 
the OFC system back to the disconnect 
state. This happens when the loss-of- 
light condition (LOL=1) occurs after the 
decode 2 time period has expired (i.e. 
Di=0O and D2=0). Since an optical 
signal remained present throughout the 
decode 2 time period (1255 usec), the 
OFC system assumes that the other end 
of the link does not have a compatible 
safety control system and_ therefore 
rejects the link connection attempt. 


3. Reconnect state: 


In’ the reconnect state each of the 
transceiver units must once again send and 
receive an optical signal to proceed to the 
active state. This verifies that a closed and 
safe link exists between’ the two 
transceivers. The function of the OFC 
system is different for the master (MAS = 1) 
and slave (MAS=0) in this state. If a 
transceiver unit responded to an _ optical 
signal in the disconnect state (i.e. MAS =O), 
it is important that it also responds in the 
reconnect state and does not attempt to ini- 
tiate the send/receive exchange. When the 
OFC system enters the reconnect state, 
decode 2 is high (D2=1) and the laser is dis- 
abled. The OFC system continues to keep 
the laser disabled until the decode 2 time 
period expires, then one of the following 
sequences of events occur: 


A. If the transceiver is master of the con- 
nection attempt (i.e. MAS=1), then 
decode 3 is set high (D3=1) and the 
laser is activated for the duration of the 
decode 3 time period (405 usec). If 
during the decode 3 time period an 
optical signal is received in response to 
this initiating light pulse (i.e. D3=1 and 
LOL=0), then the OFC system exits to 
the active state. Otherwise, when the 
decode 3 time period ends (D2=0 and 
D3=0), the OFC system disables the 
laser and exits to the disconnect state. 


B. If the transceiver is slave of the con- 
nection attempt (i.e. MAS=0), then 
decode 3 is set high (D3=1) but the 
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laser is not activated. If during the 
decode 3 time period (405 usec) an initi- 
ating optical signal is received from the 
master (i.e. D3=1 and LOL=0O), then the 
OFC system activates the laser in order 
to send a response and exits to the 
active state. Otherwise, when the 
decode 3 time period ends (D2=0 and 
D3=0), the OFC system keeps the laser 
disabled and exits to the disconnect 
state. 


4. Active state: 


In the active state the OFC system allows the 
laser to function continuously and monitors 
the two loss-of-light detectors. The OFC 
system will remain in the active state for as 
long as an optical signal is received by both 
of the detectors (i.e. LOL=0). If either of the 
detectors sense a loss-of-light condition, the 
laser is disabled, the loss-of-light flag is set 
high (LOL=1) and the OFC system exits to 
the disconnect state. 


H.2 Laser Safety Standards and OFC 
Timing Specifications 


H.2.1 Laser Safety Standards 


Although there is a considerable amount of simi- 
larity between the laser safety standards and 
regulations that exist throughout the world, some 
requirements differ, especially with respect to 
labeling and certification. Within the U.S., all 
laser products must be certified by the manufac- 
turer to conform to the requirements contained 
in the F.D.A. regulation 21 CFR subchapter J. In 
addition, it may be a business requirement to 
conform to the 2136.2 laser safety standard 
produced by the American National Standards 
Institute (ANSI). Outside of the U.S., many coun- 
tries base their laser safety regulations on the 
International Electrotechnical Commission (IEC) 
825 laser safety standard. The time values used 
for the OFC system in this Fibre Channel 
standard are based on the emission require- 
ments for Class 1 laser products contained in 
the IEC 825 standard (1984 plus amendment 1, 
1990). The reason this standard was used over 
the other two is that the IEC emission require- 
ments for a Class 1 system are more restrictive 
and the goal was to specify an OFC system 
interface which satisfies worldwide Class 1 emis- 
sion requirements. 
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H.2.2 The OFC Timing Specifications 


An optical fibre transmission system is a closed 
system (i.e. no accessible laser emissions) 
during normal link operating conditions and 
therefore a Class 1 system. It is only during 
maintenance and service conditions when the 
optical path has been accidentally or 
purposefully broken that access to laser emis- 
sions is possible. The point in the transmission 
system that will always have the largest emis- 
sion level is at the transmitter receptacle of a 
transceiver. Classification is therefore based on 
the maximum emission level at the transmitter 
receptacle. This maximum value is a worst case 
value and includes variations due to temperature 
effects, lifetime effects and single faults. 


The OFC system makes use of a repetitive 
pulsing technique (t microsec on every T sec) 
during the time that a link is open (i.e. the dis- 
connect state) in order to reduce the maximum 
possible exposure to a value which is below the 
level set by the safety standard IEC 825 for Class 
1 operation. The maximum power level per 
pulse is a function of the wavelength, pulse 
duration (t), and pulse repetition frequency (PRF 
= 1/T) which determines the number of pulses 
(N) that occur during the time base used for 
Classification. Note that the use of the word 
“pulse” refers to the time, t, during which the 
laser is powered on and being modulated with a 
valid full rate data pattern. From a laser safety 
point of view, this “pulse” can be thought of as a 
CW pulse of duration t and power level equal to 
the average power of the modulated signal. 


The OFC system described above contains a 
natural potential for a two pulse emission every 
~T seconds when only one of the two linking 
fibres is disconnected. This condition will occur 
if the optical transmission path from transceiver 
A to B is open, but the path from B to A is 
closed, and the T sec timer on transceiver A is 
sufficiently faster than the T sec timer on 
transceiver B. Transmitter A will emit a t usec 
pulse when its timer expires (i.e. D1=1) in an 
attempt to link up as master. This will fail since 
the link is open. A second t usec pulse will be 
emitted by transmitter A in response to trans- 
mitter B sending a pulse to receiver A along the 
closed part of the link. Since the timer on 
transceiver A is faster than that on B, this 
pattern will be repeated until the link is repaired. 
Hence the worst case scenario is one that 
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includes two (t usec) pulses every T seconds; 
this must be taken into consideration in any 
safety calculations. 


The accessible emission limit (AEL) is defined as 
the maximum accessible laser emission level for 
a particular classification. For the repetitively 
pulsed situation found in the OFC system, the 
AEL for the pulse train is 


—0,25 
AELtrain = AELsingie X N 


where: 
AEL train 
= exposure from any single pulse in 
the train 
AEL single 
= AEL for a single pulse 
N 


number of pulses during the 
applicable time base 


The Class 1 AEL for a single pulse in the wave- 
length range 700 to 1050 nm and emission dura- 
tion, t, between 1.8 x 10-° and 1 000 sec is given 
by the equations: 


AEL single = 7X 10~* 1°"? Cy J 
= 0.7t-°? Cc, mw 

and 

a 49(4—-700)/500 


4,38 (A = 770nm) 


The change from energy units to power units 
was used since the power level is essentially 
constant during the emission duration. For a 
maximum pulse duration of t = 410 usec, the 
single pulse AEL is 


AEL singe = 6.79 mW (t = 410 psec). 


For wavelengths greater than 400 nm and situ- 
ations where intentional viewing is not inherent 
in the design of the product, the time base is 
1000 sec. Thus the worst case number of pulses 
during the time base is 


1000 
T 


N = ( )x2 = 171 pulses (T= 11,7 sec) 


where T is the minimum pulse repetition time (T 
= 11,7 sec) and the two pulse potential has 
been included. The worst case (i.e. smallest) 
AEL for the train of pulses can now be calculated 
and is found to be 


AELipain = 6,79 X (171) = 1,88 mW 


Comparing this value to the worst case (i.e. 
maximum) transmitter receptacle power, 1,70 
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mW, we find that the specified maximum value is 
less than the AEL for the train of pulses and 
allows for a 10% guard band. Thus, a point-to- 
point optical fibre transmission system that 
implements the OFC system as described in this 
Standard should be classifiable as a Class 1 
laser system with respect to the IEC 825 
Standard (1984 plus amendment 1, 1990). 
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Annex Il. Raw Data Mode 


In order to provide complete diagnostic capa- 
bility within a Port implementation, a Port may 
choose implement an optional means by which 
an Upper Level Protocol (FC-4) may transmit raw 
10B data. This raw data could include frames, 
Primitive Signals, Idles, or Primitive Sequences. 


In order to test a Port’s error detection logic, it 
maybe helpful to transmit code violations, invalid 
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ordered sets, and other alterations of the 
encoded bit stream. In order to avoid damage to 
FC-0 components, FC-0 shall define a set of rules 
which limits the deviation allowed from a set of 
minimum operating characteristics. 


This list of rules is to be defined and contained 
in this appendix for guidelines to an implementa- 
tion which desires implementing such an option. 
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Annex J. FC-1 Service interface (informative) 


FC-1 presents a decoded-Transmission-Word- 
oriented service interface to FC-2. This interface 
uses the same primitive types as those defined 
by the OSI model. 


The FC-1 service interface provides a conceptual 
view of FC-1 function from the perspective of the 
FC-2 level and does not restrict FCS implementa- 
tion flexibility. The following figure graphically 
portrays the Fiber Channel conceptual model as 
applied to the FC-1 service interface: 


Port A Port B 


FC-2 FC-1 FC-2 FC-1 
initiated initiated 
function function 


initiated initiated 


Service Users 


er3saqongsnwnw wD 
no a: i; ee = a | 


Figure 81. FC-1 Service Interface 


Primitives are of four generic types: 


Request The request primitive is passed from 
the FC-2 level to the FC-1 level to 


request that a service be initiated. 


Indication The indication primitive is passed 
from the FC-1 level to the FC-2 level 
to indicate an internal FC-1 event 
which is significant to the FC-2 level. 
This event may be logically related 
to a remote service request, or may 
be caused by an event internal to 
the FC-1 level. 


Response The response primitive is passed 
from the FC-2 level to the FC-1 level 
to complete a procedure previously 
invoked by an indication primitive. 


Confirm The confirm primitive is passed from 
the FC-1 level to the FC-2 level to 
convey the results of one or more 
associated previous service 


request(s). 


Figure 82 illustrates the primitive combinations 
that are supported by the FC-1 service interface. 
Each primitive described in this section of the 
standard is correlated to one of the subfigures 
(a), (b), (c), or (d) of figure 82. This figure also 
indicates the logical relationship of the primitive 
types. Primitive types that occur earlier in time 
and are connected by dotted lines in the dia- 
grams are the logical antecedents of subsequent 
primitive types. 


(a) (b) 


Request 


———— > \ 
\ Indication 
t+-+-o_—-——————— 
\ Indication 
\i-— 
FC-2 FC-2 FC-2 FC-2 
Port A Port B Port A Port B 
(c) (d) 
Request 
bene ot 
Request 
—_—_—_———P 
Confirm 
<¢----_————— 
FC-2 FC-2 FC-2 FC-2 
Port A Port B Port A Port B 


NOTE - The Response primitive is not used by 
the FC-1 service interface. 


Figure 82. FC-1 Service Interface Primitive Com- 
binations 
The following service primitives are defined by 
the FC-1 service interface: 
- FC-1_Receiver_ State 
- Indication 
- FC-1_Transmitter_ State 
- Indication 
- FC-1 Data Path Width * 


- Request 
- Confirm 
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- FC-1_Transmitter_Clock 
- Indication 
- FC-1_ Data 


- Request 
- Indication 


- FC-1_Receiver_Control 
- Request 
- FC-1_Transmitter_Control 
- Request 
- FC-1_Loopback_Control 
- Request 
- Confirm 


*: optional primitive 


J.1 FC-1_Receiver_State 


J.1.1 FC-1_Receiver_State.Indication 


J.1.1.1 Function 


This primitive is used by the FC-1 level to indi- 
cate the state of its Receiver to an associated 
FC-2 level. 


J.1.1.2 Semantics 


The FC-1_Receiver_State.Indication service prim- 
itive is defined as follows: 


FC-1_ Receiver _State.Indication(State) 


State The functional state of the FC-1 level’s 
Receiver. The allowable values of this 
parameter are Loss Of Signal Failure, 
Loss _Of_Synchronization Failure, 
Loss_Of_Synchronization, 
Synchronization Acquired, Offline, and 
Reset. The format of this parameter is 
not defined by the standard. 


J.1.1.3 When generated 


An FC-1 level issues the 
FC-1 Receiver _State.Indication primitive with 
state = Loss Of_ Signal Failure to indicate to 


the FC-2 level that its Receiver has been unable 
to achieve Synchronization (i.e., has been in the 
Loss-Of-Synchronization state for an extended 
period of time as defined by FC-O) and is cur- 


rently not receiving a signal from its attached 
Fibre. This state may be entered from the Loss- 
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Of-Synchronization and Loss-Of-Synchronization- 
Failure States. While in the 
Loss-Of-Signal-Failure state, the FC-1 Receiver is 
considered Not Operational and does not 
provide FC-1 Data.Jndication primitives to the 
FC-2 level. 


An FC-1 level issues the 
FC-1 Receiver State.Indication primitive with 
State = Loss _Of_Synchronization Failure to 


indicate to the FC-2 level that its Receiver has 
been unable to achieve Synchronization (i.e., 
has been in the Loss-Of-Synchronization state 
for an extended period of time as defined by 
FC-0) but is currently receiving a signal from its 
attached Fibre. (See 11.1.2.2 for a description of 
Synchronization.) This state may be entered 
from the Loss-Of-Synchronization and Loss-Of- 
Signal-Failure states. While in the Loss-Of- 
Synchronization-Failure state, the FC-1 Receiver 
is considered Not Operational and does not 
provide FC-1 Data.Indication primitives to the 
FC-2 level. 


An FC-1 level issues the 
FC-1_ Receiver State. Indication primitive with 
State = Loss Of Synchronization to indicate to 
the FC-2 level that its Receiver has lost Synchro- 
nization on the signal received from its attached 
Fibre. (See 11.1.2.2 for a description of Synchro- 
nization.) This state may be entered from the 
Synchronization-Acquired or Reset states. While 
in the Loss-Of-Synchronization state, the FC-1 
Receiver is considered Operational but does not 
provide FC-1 Data.Indication primitives to the 
FC-2 level. 


An FC-1 level issues the 
FC-1 Receiver State.Indication primitive with 
State = Synchronization Acquired to indicate to 
the FC-2 level that its Receiver has achieved 
Synchronization on the signal received from its 
attached Fibre. (See 11.1.2.2 for a description of 
synchronization.) This state may be entered 
from the Loss-Of-Synchronization or Offline 
states. While in the Synchronization-Acquired 
state, the FC-1 Receiver is considered Opera- 
tional and provides FC-1 Data.Indication primi- 
tives to the FC-2 level according to the rules 
described in J.5. 


An FC-1 level issues the 
FC-1_ Receiver State.Indication primitive with 
State = Offline to indicate to the FC-2 level that 
it has received and processed an 
FC-1_Receiver_Control primitive from FC-2 with 


Control = _ Enter Offline while in the 
Synchronization-Acquired state or that it has 
completed a previously requested reset and is 
returning to the Offline state. This state may be 
entered from the Synchronization-Acquired or 
Reset states. While in the Offline state, the FC-1 
Receiver is considered Operational and provides 
FC-1 Data.Indication primitives to the FC-2 level 
according to the rules described in J.5. The 
Receiver continues to process received Trans- 
mission Words under the rules of the Loss-of- 
Synchronization procedure specified in “Invalid 
Transmission Word rules,” but completion of the 
procedure does not cause the Receiver to enter 
the Loss-Of-Synchronization state. 


An FC-1 level issues the 
FC-1 Receiver_State.Indication primitive with 
State = Reset to indicate to the FC-2 level that it 
has initiated a reset condition at its Receiver. 
This state may be entered from any other state. 
While in the Reset state, the FC-1 Receiver is 
considered Not Operational and does not 
provide FC-1 Data.Indication primitives to the 
FC-2 level. 


J.1.1.4 Effect on receipt 


Receipt of this primitive with State = 
Synchronization Acquired causes the FC-2 level 
to prepare to accept FC-1_ Data.Indication primi- 
tives from the FC-1 level. Receipt of this primi- 
tive with State =  Loss_Of_Synchronization 
notifies the FC-2 level that FC-1 Data.Indication 
primitives will not be forthcoming from the FC-1 
level. Receipt of this primitive with State = 
Loss_Of Synchronization Failure or 
Loss Of Signal Failure notifies the FC-2 level 
that the FC-1 level is incapable of reception and 
may cause the FC-2 level to initiate maintenance 
activity. Receipt of this primitive with State = 
Offline notifies the FC-2 level that the FC-1 level 
has processed the FC-2 request to enter the 
Offline state or has completed the previously 
requested reset and presents 
FC-1 Data.Indication primitives to the FC-2 level. 
It also continues to process received Trans- 
mission Words under the rules of the Loss-of- 
Synchronization procedure specified in “Invalid 
Transmission Word rules,” but completion of the 
procedure does not cause the Receiver to enter 
the Loss-Of-Synchronization state. Receipt of 
this primitive with State = Reset notifies the 
FC-2 level that the FC-1 level is incapable of 
reception because it has had a Receiver reset 
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condition imposed upon it, either internally or 
externally. 


J.1.1.5 Additional comments 


The Loss-Of-Synchronization state is the default 
state of an FC-1 level’s Receiver upon com- 
pletion of Initialization. 


This primitive is illustrated by figure 82 (b). 


J.2 FC-1_Transmitter_State 


J.2.1 FC-1_Transmitter_State.Indication 


J.2.1.1 Function 


This primitive is used by the FC-1 level to indi- 
cate the state of its Transmitter to an associated 
FC-2 level. 


J.2.1.2 Semantics 
The FC-1_Transmitter_State.Indication service 
primitive is defined as follows: 


FC-1_ Transmitter_State.Indication(State) 


State The functional state of the FC-1 level’s 
Transmitter. The allowable values of this 
parameter are Failure, Not_Enabled, and 
Working. The format of this parameter is 
not defined by the standard. 


J.2.1.3 When generated 


An FC-1 level issues the 
FC-1 Transmitter State.Indication primitive with 
State = Failure to indicate to the FC-2 level that 
its Transmitter has entered the Failure state as 
described by 11.3.4. This state may be entered 
from the Working or Not-Enabled states. While 
in the Failure state, the FC-1 Transmitter is con- 
sidered Not Operational, does not accept 
FC-1 Data.Request primitives from the FC-2 
level, and does not provide 
FC-1 Transmitter_Clock.Indication primitives to 
the FC-2 level. 


An FC-1 level issues the 
FC-1_ Transmitter_State.Indication primitive with 
State = Not_Enabled to indicate to the FC-2 
level that its Transmitter is Operational but is 
prevented from transmitting a signal onto its 
associated Fibre. This state may be entered 
from the Working state. It may result from the 
processing of an 
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FC-1_Transmitter_Control.Request primitive or 
from detection by FC-0O laser safety procedures 
of a laser safety condition (i.e., a condition which 
requires that the Transmitter cease trans- 
mission). While in the Not-Enabled state, the 
FC-1 Transmitter is considered Operational and 
accepts FC-1 Data.Request primitives from the 
FC-2 level in synchronization with the 
FC-1_Transmitter_Clock.Indication primitives pro- 
vided by it to the FC-2 level. However, no 
signals resulting from the accepted 
FC-1 Data.Request primitives are transmitted 
onto its associated Fibre. If the FC-1 level is in 
Loopback mode, the encoded bit stream 
resulting from the accepted FC-1 Data.Request 
primitives is provided to the FC-1 Receiver. 


An FC-1 level issues the 
FC-1_ Transmitter _State.Indication primitive with 
State = Working to indicate to the FC-2 level 
that its Transmitter is operating normally 
according to the error-monitoring procedure 
described by 11.3.4. This state may be entered 
from the Not-Enabled state. While in the 
Working state, the FC-1 Transmitter is consid- 


ered Operational and accepts 
FC-1 Data.Request primitives from the FC-2 level 
in synchronization with the 


FC-1_Transmitter_Clock.Indication primitives pro- 
vided by it to the FC-2 level. Signals resulting 
from the accepted FC-1 Data.Request primitives 
are transmitted onto its associated Fibre. If the 
FC-1 level is in Loopback mode, the encoded bit 
stream resulting from the accepted 
FC-1 Data.Request primitivés are also provided 
to the FC-1 Receiver. 


J.2.1.4 Effect on receipt 


Receipt of this primitive with State = Working 
causes the FC-2 level to continue issuance of 
FC-1 Data.Request primitives to the FC-1 level 
(synchronous to 
FC-1_Transmitter_Clock.Indication primitives 
from the FC-1 level). Receipt of this primitive 
with State = Not_Enabled causes the FC-2 level 
to begin or continue issuance of 
FC-1 Data.Request primitives to the FC-1 level 
(synchronous to 
FC-1_Transmitter_Clock.Indication primitives 
from the FC-1 level). No transmitted signals 
result from the receipt of FC-1_Data.Request 
primitives. The Transmitter remains Opera- 
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tional. Receipt of this primitive with State = 
Failure notifies the FC-2 level that 
FC-1_ Transmitter_Clock.Indication primitives will 
not be forthcoming from the FC-1 level and that 
FC-1 Data.Request primitives will not be 
accepted by the FC-1 level. The FC-2 level may 
initiate maintenance activity. 


J.2.1.5 Additional comments 


The Not-Enabled state is the default state of an 
FC-1 level’s Transmitter upon completion of 
Initialization. 


This primitive is illustrated by figure 82 (b). 


J.3 FC-1_Data Path Width 


J.3.1 FC-1_Data_Path_Width.Request 


J.3.1.1 Function 


This primitive is used to establish the path width 
of a variable-width data interface between an 
FC-1 and an FC-2 level. 


J.3.1.2 Semantics 
The FC-1 Data Path Width.Request 
primitive is defined as follows: 

FC-1 Data_Path Width.Request(Width) 
Width 


service 


The data path width of the interface 
between the FC-1 and FC-2 levels. The 
allowable values of this parameter are 
Byte, Half_Word, and Word. The format 
of this parameter is not defined by the 
standard. 


J.3.1.3 When generated 


An FC-2 level issues the 
FC-1_ Data Path Width.Request primitive to 
specify to the FC-1 level the width of the data 
path to be used (Byte, Half Word, or Word) 
between the FC-1 and FC-2 levels. 


J.3.1.4 Effect on receipt 


Receipt of the FC-1 Data_Path Width.Request 
primitive causes an FC-1 level to attempt to 
establish the requested path width for its data 
interface to FC-2. 


J.3.1.5 Additional comments 


This primitive is not required for those imple- 
mentations which use an FC-1 level with a fixed 
data path width. For those implementations 
which use an FC-1 level with a variable data 
path width, the attached FC-2 level issues this 
primitive to indicate the preferred path width. 


An FC-1 Data Path Width.Request primitive is 
accepted by an FC-1 level or a fixed data path 


width is defined before FC-1 Data and 
FC-1 Transmitter Clock primitives can be 
issued. 


The Half_ Word value of Width corresponds to a 
2-byte interface. The Word value of Width corre- 
sponds to a 4-byte interface. 


This primitive is illustrated by the request 
portion of figure 82 (c). 


J.3.2 FC-1_Data_Path_Width.Confirm 


J.3.2.1 Function 


This primitive is used to accept or reject the 
establishment of the path width of a variable- 
width data interface between an FC-1 and an 
FC-2 level. 


J.3.2.2 Semantics 


The FC-1_Data_Path Width.Confirm service prim- 
itive is defined as follows: 


FC-1 Data Path Width.Confirm(Status) 


Status The results of the 
FC-1 Data Path Width.Request _ primi- 
tive. The allowable values of this 
parameter are Accept and Reject. The 
format of this parameter is not defined 
by the standard. 


J.3.2.3 When generated 


An FC-1 level issues the 
FC-1 Data_Path Width.Confirm primitive to an 
FC-2 level to indicate the acceptance or rejection 
of a previously issued 
FC-1_ Data_Path Width.Request primitive. 
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J.3.2.4 Effect on receipt 


Receipt of the FC-1 Data Path Width.Indication 
primitive with Status = Accept informs the FC-2 
level that path width establishment was suc- 
cessful. Receipt of the 
FC-1 Data Path Width.Indication primitive with 
Status = Reject informs the FC-2 level that path 
width establishment was unsuccessful. 


J.3.2.5 Additional comments 


This primitive is not required for those imple- 
mentations which use an FC-1 level with a fixed 
data path width. For those implementations 
which use an FC-1 level with a variable data 
path width, the attached FC-1 level must issue 
this primitive in response to an 
FC-1 Data_Path_Width.Request primitive. 


This primitive is illustrated by the confirm 
portion of figure 82 (c). 


J.4 FC-1_Transmitter_Clock 


J.4.1 FC-1_Transmitter_Clock.Iindication 


J.4.1.1 Function 


This primitive is used by the FC-1 level to 
provide data transmission synchronization infor- 
mation, including an indication of Transmission 
Word alignment boundaries, to the FC-2 level. 


J.4.1.2 Semantics 


The FC-1_ Transmitter Clock service primitive is 
defined as follows: 


FC-1 Transmitter_Clock.Indication(Boundary) 


Boundary An _ indication of the transmission 
boundary presented by the Trans- 
mitter clock. The allowable values of 
this parameter are Word and Null. 
The format of this parameter is not 
defined by the standard. 


J.4.1.3 When generated 


An FC-1 level with a Transmitter in the Working 
or Not-Enabled states issues the 
FC-1 Transmitter_Clock.Indication primitive to 
provide a data transmission § synchronization 
signal to the FC-2 level. Synchronous to the 
receipt of an FC-1_ Transmitter _Clock.Indication 
primitive, the FC-2 level may choose to issue an 
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FC-1 Data.Request primitive to the FC-1 level to 
present data to be transmitted (see J.5 for a 
description of the rules associated with data 
transmission). 


The FC-1 Transmitter_Clock.Indication primitive 
is issued periodically to the FC-2 level with a fre- 
quency based upon the FC-0 transmission fre- 
quency and the data path width between the 
FC-1 and FC-2 levels. When a byte-wide data 
path is provided, the frequency of issuance = 
FC-0 transmission frequency / 10. When a half- 
word-wide data path is provided, the frequency 
of issuance = FC-0 transmission frequency / 20. 
When a word-wide data path is provided, the fre- 
quency of issuance = FC-0 transmission fre- 
quency / 40. 


The Boundary parameter is used by the FC-1 
level to indicate whether the transmission data 
presented on an FC-1 Data.Request primitive 
that is associated with the 
FC-1_Transmitter_Clock.Indication primitive may 
be of the type that requires a Transmission-Word 
boundary. When Boundary = Word, any infor- 
mation type (Valid Data_Byte, Delimiter, or 
Primitive Signal) may be presented on the Type1 
parameter of the associated FC-1 Data.Request 
primitive. When Boundary = Null, only the type 
Valid _Data_Byte may be presented on the Type‘ 
parameter of the associated FC-1 Data.Request 
primitive. 


Transmission-Word alignment is established by 
an FC-1 Transmitter at the time it enters the 
working state and begins to transmit idle words 
as specified in  J.5. The = established 
Transmission-Word alignment is indicated by the 
FC-1 level to the FC-2 level through the 
FC-1_Transmitter_Clock.Indication primitive. 
When a byte-wide data path width has been 
specified, the  FC-1 level indicates a 
Transmission-Word boundary on every fourth 
FC-1_Transmitter_Clock.Indication primitive. 
When a half-word-wide data path width has been 
specified, the FC-1 level indicates = a 
Transmission-Word boundary on every second 
FC-1_Transmitter_Clock.Indication primitive. 
When a word-wide data path width has been 
specified, the FC-1 level indicates a 
Transmission-Word boundary on every 
FC-1_Transmitter_Clock.Indication primitive. 
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J.4.1.4 Effect on receipt 


Receipt of this primitive informs an FC-2 level 
that a request for information transmission can 
occur via issuance of an FC-1_Data.Request 
primitive. 


J.4.1.5 Additional comments 


This primitive is illustrated by figure 82 (b). 


J.5 FC-1_Data 


J.5.1 FC-1_Data.Request 


J.5.1.1 Function 


This primitive is used by the FC-2 level to pass 
transmission requests to an associated FC-1 
level. 


J.5.1.2 Semantics 


The FC-1 Data service primitive is defined as 
follows: 


FC-1 Data.Request(Type1, Code‘ 
Type2, Code2 
Type3, Code3 
Type4, Code4) 


Type The type of transmission information that 
is to be encoded and transmitted by the 
FC-1 level. The allowable values of this 
parameter are Valid Data Byte, 
Non_Repeating Ordered_ Set, and 
Repeating Ordered Set. The format of 
this parameter is not defined by the 
standard. 


When a Non-Repeating Ordered Set or 
Repeating Ordered Set is indicated, a 
single Type field (Type1) is provided 
regardless of data path width. When a 
Valid Data Byte is indicated, a separate 
Type field is provided for each byte of 
the data path (i.e., Type1 is provided 
when a byte-wide data path width is 
specified, Type1 and Type2 are provided 
when a half-word-wide data path width is 
specified, and Type1, Type2, Type3, and 
Type4 are provided when a word-wide 
data path width is specified). 


The values Non Repeating Ordered Set 
and Repeating Ordered Set are 
restricted to the Type1 parameter. When 


Code 


present, the Type2, Type3, and Type4 
parameters are set to the 
Valid _Data_Byte value. 


When multiple Type parameters are pre- 
sented in an FC-1_Data.Request primi- 
tive, the corresponding Transmission 
Characters are transmitted in the order 
given (i.e., Type1 corresponds to the first 
character received, followed by Type2, 
Type3 (if present), and Type4 (if 
present)). 


The Valid Data Byte or Ordered Set that 
is to be encoded and transmitted by the 
FC-1 level. The contents of the Code 
parameter are defined as follows: 


- When Type = Valid Data Byte, the 
Code parameter contains information 
in. a format not defined by the 
standard which indicates the Valid 
Data Byte. 


- When Type = 
Non_Repeating Ordered Set the 
Code parameter contains information 
in a format not defined by the 
standard which indicates the Non- 
Repeating Ordered Set. All Ordered 
Sets specified in 10.3, “Ordered 
Sets” may be specified as a Non- 
Repeating Ordered Set. 


- When Type = 
Repeating Ordered Set, the Code 
parameter contains information in a 
format not defined by the standard 
which indicates the Repeating 
Ordered = Set. Only Primitive 
sequences and the Idle Primitive 
Signal may be specified as 
Repeating Ordered Sets. 


When a Repeating Ordered Set or Non- 
Repeating Ordered Set is indicated, a 
single Code field (Code1) is provided 
regardless of data path width. When a 
Valid Data Byte is indicated by Type, a 
separate Code field is provided for each 
byte of the data path (i.e., Code1 is pro- 
vided when a byte-wide data path width 
is specified, Code1 and Code2 are pro- 
vided when a half-word-wide data path 
width is specified, and Code1, Coded2, 
Code3, and Code4 are provided when a 
word-wide data path width is specified). 
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When multiple Code parameters are pre- 
sented in an FC-1 Data.Request primi- 
tive, the corresponding Transmission 
Characters are transmitted in the order 
given (i.e., Code1 corresponds to the first 
character received, followed by Coded2, 
Code3 (if present), and Coded (if 
present)). 


J.5.1.3 When generated 


An FC-2 level issues the FC-1 Data.Request 
primitive to the FC-1 level synchronous to a 
received FC-1_ Transmitter_Clock.Indication prim- 
itive when it wishes to specify information to be 
encoded and transmitted by the FC-1 level. 
Information to be encoded is passed by the FC-2 
level to the FC-1 level according to the following 
rules: 


1. When the data path width between the FC-1 
and FC-2 levels is defined to be Byte, the 
information passed by the 
FC-1 Data.Request primitive may be a Valid 
Data Byte, a Non-Repeating Ordered Set, or 
a Repeating Ordered Set. If a Repeating 
Ordered Set or Non-Repeating Ordered Set 
is passed by the FC-1 Data.Request primi- 
tive, the FC-2 level does not issue an 
FC-1 Data.Request primitive synchronous to 
the following three received 
FC-1_ Transmitter_Clock.Indication primitives. 


2. When the data path width between the FC-1 
and FC-2 levels is defined to be Half Word, 
the information passed by the 
FC-1 Data.Request primitive may be two 
Valid Data Bytes, a Non-Repeating Ordered 
set, or a Repeating Ordered Set. If a 
Repeating Ordered Set or Non-Repeating 
Ordered set is passed by the 
FC-1 Data.Request primitive, the FC-2 level 
does not issue an FC-1_ Data.Request primi- 
tive synchronous to the following received 
FC-1_ Transmitter _Clock.Indication primitive. 


3. When the data path width between the FC-1 
and FC-2 levels is defined to be Word, the 
information passed by the 
FC-1 Data.Request primitive may be four 
Valid Data Bytes, a Repeating Ordered Set, 
or a Non-Repeating Ordered Set. 


The Boundary parameter of the 
FC-1_ Transmitter_Clock.Indication primitive may 
restrict what an FC-2 level is allowed to present 
on an FC-1 Data.Request primitive. When 


217 


FC-PH REV 2.1, May 25, 1991 


Boundary = Word, any _ information § type 
(Valid Data Byte, Non Repeating Ordered Set, 
or Repeating Ordered Set may be presented on 
the Type1 parameter of the associated 
FC-1 Data.Request primitive. When Boundary = 
Null, only Valid Data_Byte may be presented on 
the Type1 parameter of the associated 
FC-1 Data.Request primitive. When information 
types other than Valid Data Byte are presented, 
unpredictable Transmitter behavior results and 
the Transmitter enters the Failure state. 


J.5.1.4 Effect on receipt 


Receipt of an FC-1_Data.Request primitive by an 
FC-1 Transmitter in the Not-Enabled state causes 
the FC-1 level to attempt to encode the data indi- 
cated by the primitive. If the FC-1 level is in 
Loopback mode, data are provided to the FC-1 
Receiver for decoding and presentation to the 
FC-2 level. No signal is transmitted onto the 
attached Fibre as the’ result of a 
FC-1 Data.Request primitive received by an FC-1 
Transmitter in the Not-Enabled state. 


Receipt of an FC-1_ Data.Request primitive by an 
FC-1 Transmitter in the Working state causes the 
FC-1 level to attempt to encode and transmit the 
data indicated by the primitive onto its attached 
Fibre. If the FC-1 level is in Loopback mode, this 
data is also provided to the FC-1 Receiver for 
decoding and presentation to the FC-2 level. 


Encoded information is processed by an FC-1 
Transmitter in the Working or Not-Enabled states 
according to the following rules: 


1. Upon entering the Working state, the FC-1 
Transmitter continuously transmits and/or 
provides encoded idle words until receipt of 
an FC-1 Data.Request primitive. (See table 
24 for the definition of the idle word.) 


2. Upon receipt of an FC-1_Data.Request primi- 
tive specifying Repeating Ordered Set, the 


FC-1 Transmitter begins transmitting and/or: 


providing the specified encoded Ordered Set 
and continues to transmit and/or provides 
this Ordered Set until receipt of a subse- 
quent FC-1_Data.Request primitive. 


3. Upon receipt of an FC-1_ Data.Request primi- 
tive specifying Valid _Data_Byte or 
Non_Repeating Ordered Set the FC-1 Trans- 
mitter encodes and transmits and/or provide 
the specified information. Receipt of such an 
FC-1 Data.Request primitive ends the contin- 
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uous transmission and/or provision. of 
Repeating Ordered Sets if such transmission 


and/or provision has been previously estab- 


lished by a prior FC-1_Data.Request primi- 
tive. 


. If an FC-1 Data.Request is not received by 


the FC-1 level synchronous to- an 
FC-1_ Transmitter _Clock.Indication primitive 
representing a word boundary  ({i.e., 


Boundary = Word) and the 
FC-1 Data.Request received synchronous to 
the immediately previous 


FC-1_Transmitter_Clock.Indication primitive 
representing a word boundary specified 
Valid_Data_Byte or 
Non_Repeating Ordered Set the FC-1 level 
continuously transmits and/or provides 
encoded idle words until the subsequent 
receipt of an FC-1_Data.Request primitive. 


. If an FC-1_Data.Request is not received by 


the FC-1 level synchronous to- an 
FC-1_Transmitter_Clock.Indication primitive 
not representing a word boundary (i.e., 


Boundary = Null) and the 
FC-1_Data.Request received synchronous to 
the immediately previous 


FC-1 Transmitter_Clock.Indication primitive 
representing a word boundary specified 
Valid Data_Byte, unpredictable FC-1 level 
behavior results and the Transmitter enters 
the Failure state. 


. If an FC-1_Data.Request is received by the 


FC-1 level synchronous to an 
FC-1 Transmitter_Clock.Indication primitive 
not representing a word boundary (i.e., 


Boundary = Null) and the 
FC-1 Data.Request received synchronous to 
the immediately previous 


FC-1 Transmitter _Clock.Indication primitive 
representing a word boundary specified 
Non Repeating Ordered Set or 
Repeating Ordered Set, unpredictable FC-1 
level behavior results and the Transmitter 
enters the Failure state. 


. If an FC-1 Data.Request is received by the 


FC-1 level synchronous to an 
FC-1_Transmitter_Clock.Indication primitive 
not representing a word boundary (i.e., 
Boundary = Null) and the FC-1 level is con- 
tinuously transmitting and/or providing a 
Repeating Ordered Set, unpredictable FC-1 
level behavior results and the Transmitter 
enters the Failure state. 


Receipt of an FC-1 Data.Request primitive not 
conforming to the rules described previously 
results in unpredictable FC-1 level behavior and 
the Transmitter enters the Failure state. 


Encoded information is not transmitted and/or 
provided and FC-1 Data.Request primitives are 
not accepted by an FC-1 Transmitter in the 
Failure state. 


J.5.1.5 Additional comments 


This primitive is illustrated by the 
portion of figure 82 (a). 


request 


J.5.2 FC-1_Data.Indication 


J.5.2.1 Function 


This primitive is used by the FC-1 level to pass 
received and decoded data to an associated 
FC-2 level. 


J.5.2.2 Semantics 


The FC-1_Data.Indication service primitive is 
defined as follows: 


FC-1 Data.Indication(Type1, Code1 
Type2, Code2 
Type3, Code3 
Type4, Code4) 


The type of transmission information that 
has been received and decoded by the 
FC-1 level. The allowable values of this 
parameter are Valid Data Byte, 
Ordered Set, Special Code, 
Code_Violation, 

Invalid Special_ Code Alignment, and 
Reserved Special Code Violation. (The 
latter three values are associated with 
the detection of invalid Transmission 
Words as specified by “Invalid Trans- 
mission Word rules.” Special Codes and 
Valid Data Bytes may be reported in con- 
junction with these values as defined by 
the rules specified in J.5.2.3.  ) The 
format of this parameter is not defined 
by the standard. 


Type 


When an Ordered Set is indicated, a 
single Type field (Type1) is provided 
regardless of data path width. When 
information other than an Ordered Set is 
indicated, a separate Type field is pro- 
vided for each byte of the data path (i.e., 


Code 
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Type is provided when a byte-wide data 
path width is specified, Type1 and Type2 
are provided when a half-word-wide data 
path width is specified, and Type’, 
Type2, Type3, and Type4 are provided 
when a word-wide data path width is 
specified). 


The values Ordered Set and 
Reserved Special_Code_ Violation are 
restricted to the Type1 parameter. When 
present, the Type2, Type3, and Type4 
parameters are set to the 
Valid Data Byte, Code_Violation, 
special Code, or 
Invalid Special_Code_ Alignment value. 


When multiple Type parameters are pre- 
sented in an FC-1 Data.Indication primi- 
tive, the corresponding Transmission 
Characters were received in the order 
given (i.e., Type1 corresponds to the first 
character received, followed by Type2, 
Type3 (if present), and Type4 (if 
present)). 


The information (Valid Data Byte, 
Ordered Set, or invalid information) that 
has been received and decoded by the 
FC-1 level. The contents of the Code 
parameter are defined as follows: 


- When Type = Valid _Data_Byte, the 
Code parameter contains information 
in a format not defined by the 
Standard which indicates the Valid 
Data Byte. 


- When Type = Special Code, the 
Code parameter contains information 
in a format not defined by the 
standard which indicates the Special 
Code. 


- When Type = Ordered Set, the 
Code parameter contains information 
in a format not defined by the 
standard which indicates the Ordered 
Set. 


- When Type = 
Invalid Special Code Alignment, the 
Code parameter contains information 
in. a format not defined by the 
standard which indicates the Special 
Code that was detected in an invalid 
position in the second, third, or 
fourth character of the Transmission 
Word. 
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- When Type = 
Reserved Special Code Violation, 
the Code parameter contains infor- 
mation in a format not defined by the 
standard which indicates __ the 
reserved Special Code that was 
detected in the first character of the 
Transmission Word. 


- When Type = Code Violation, the 
Code parameter is not meaningful 
and is ignored. 


When an Ordered Set is indicated, a 
single Code field (Code1) is provided 
regardless of data path width. When 
information other than an Ordered Set is 
indicated by Type, a separate Code field 
is provided for each byte of the data path 
(i.e., Code1 is provided when a byte-wide 
data path width is specified, Code1 and 
Code2 are provided when a_ half-word- 
wide data path width is specified, and 
Code1, Code2, Code3, and Code4 are 
provided when a word-wide data path 
width is specified). (Note that the Code 
field associated with a Type field indi- 
cating Code_Violation, while present, is 
- not meaningful.) 


When multiple Code parameters are pre- 
sented in an FC-1_Data.Indication primi- 
tive, the corresponding Transmission 
Characters were received in the order 
given (i.e., Code1 corresponds to the first 
character received, followed by Code2, 
Code3 (if present), and Code4 (if 
present)). 


J.5.2.3 When generated 


An FC-1 Receiver in the Synchronization- 
Acquired or Offline state issues the 
FC-1 Data.Indication primitive to pass received 
and decoded Transmission Words to the FC-2 
level. When the FC-1 level is in normal mode, 
Transmission Words are received from the Fibre 
attached to the FC-1 Receiver. When the FC-1 
level is in Loopback mode, received Trans- 
mission Words are provided by the FC-1 Trans- 
mitter. 


Decoded Transmission Words that are deter- 
mined to be valid by the FC-1 level are passed 
to the FC-2 level according to the following rules: 


1. When the data path width between the FC-1 
and FC-2 levels is defined to be Byte, the 
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information passed by the 
FC-1 Data.Indication primitive may be a 
Valid Data Byte, a Special Code, or an 
Ordered Set. (A Special Code is passed 
only when an Unrecognized Ordered Set is 
received and decoded by the Receiver.) 


2. When the data path width between the FC-1 
and FC-2 levels is defined to be Half Word, 
the information passed by the 
FC-1 Data.Indication primitive may be two 
Valid Data Bytes, a Special Code followed by 
a Valid Data Byte, or an Ordered Set. (The 
Special Code / Valid Data Byte pair is 
passed only when an Unrecognized Ordered 
Set is received and decoded by _ the 
Receiver.) 


3. When the data path width between the FC-1 
and FC-2 levels is defined to be Word, the 
information passed by the 
FC-1 Data.Indication primitive may be four 
Valid Data Bytes, a Special Code followed by 
three Valid Data Bytes, or an Ordered Set. 
(The Special Code / Valid Data Byte / Valid 
Data Byte / Valid Data Byte string is passed 
only when an Unrecognized Ordered Set is 
received and decoded by the Receiver.) 


Decoded Transmission Words that are deter- 
mined to be invalid by the FC-1 level is passed 
to the FC-2 level according to the following rules: 


1. When the data path width between the FC-1 
and FC-2 levels is defined to be Byte, the 
information passed by the 
FC-1 Data.Indication primitive may be one of 
the following: a Code Violation, an invalid 
Special Code alignment, or a_reserved 
Special Code Violation. Preceding or subse- 
quent FC-1 Data.Indication primitives associ- 
ated with the invalid Transmission Word may 
contain Valid Data Bytes and/or Special 
Codes. (Note that an invalid Transmission 
Word as specified by “Invalid Transmission 
Word rules” may contain one or more valid 
Transmission Characters; it is these charac- 
ters that are passed as Valid Data Bytes or 
Special Codes in the four 
FC-1 Data.Indication primitives which repre- 
sent the invalid Transmission Word.) 


2. When the data path width between the FC-1 
and FC-2 levels is defined to be Half_Word, 
the —_ information passed by the 
FC-1 Data.Indication primitive may be one or 
more of the following: a Code Violation, an 
invalid Special Code alignment, or a 


reserved Special Code Violation. A reserved 
Special Code Violation may be specified only 
in the Type1 parameter. Code Violations 
and invalid Special Code alignments may be 
specified in either or both of the Type1 and 
Type2 parameters. These values may be 
combined with a Valid Data Byte or Special 
Code value in one of the Type1 and Type2 
parameters according to the contents of the 
received and decoded Transmission Word 
and the usage rules described in the defi- 
nition of the Type parameter. Preceding or 
subsequent FC-1 Data.Indication primitives 
associated with the invalid Transmission 
Word may also contain Valid Data Bytes 
and/or Special Codes. (Note that an invalid 
Transmission Word as specified by “Invalid 
Transmission Word rules” may contain one 
or more valid Transmission Characters; it is 
these characters that are passed as Valid 
Data Bytes or Special Codes in the two 
FC-1_Data.Indication primitives which repre- 
sent the invalid Transmission Word.) 


3. When the data path width between the FC-1 
and FC-2 levels is defined to be Word, the 
information passed by the 
FC-1 Data.Indication primitive may be one or 
more of the following: a Code Violation, an 
invalid Special Code alignment, or a 
reserved Special Code Violation. A reserved 
Special Code Violation may be specified only 
in the Type1 parameter. Code Violations 
may be specified in one or more of the 
Type1, Type2, Type3, and Type4 parameters. 
Invalid Special Code alignments may be 
specified in one or more of the Type2, Type3, 
and Type4 parameters. These values may 
be combined with Valid Data Byte and 
Special Code values in one or more of the 
Type1, Type2, Type3, and Type4 parameters 
according to the contents of the received and 
decoded Transmission Word and the usage 
rules described in the definition of the Type 
parameter. (Note that an invalid Trans- 
mission Word as specified by “Invalid Trans- 
mission Word rules” may contain one or 
more valid Transmission Characters; it is 
these characters that are passed as Valid 
Data Bytes or Special Codes in the 
FC-1 Data.Indication primitive which repres- 
ents the invalid Transmission Word.) 


When information other than Ordered Sets is 
received and decoded by the FC-1 level, the 
FC-1 Data.Indication primitive is issued period- 
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ically to the FC-2 level with a frequency based 
upon the FC-0 transmission frequency and the 
data path width between the FC-1 and FC-2 
levels. When a byte-wide data path is provided, 
the frequency of issuance = FC-O transmission 
frequency / 10. When a half-word-wide data path 
is provided, the frequency of issuance = FC-0 
transmission frequency / 20. When a word-wide 
data path is provided, the frequency of issuance 
= FC-0 transmission frequency / 40. When 
Ordered Sets are received by the FC-1 level, the 
FC-1 Data.Indication primitive is issued 
according to the rules described below. 


Received and decoded information is passed to 
the FC-2 level by an FC-1 Receiver in the 
Synchronization-Acquired state according to the 
following rules: 


1. Upon entering the Synchronization-Acquired 
state, the FC-1 Receiver indicates receipt of 
the Ordered Set which allowed it to enter the 
Synchronization-Acquired state. When the 
Ordered Set is recognized, this indication is 
completed by issuing an 
FC-1 Data.Indication with Type = 
Ordered Set and Code indicating the appro- 
priate value. When the Ordered Set is 
unrecognized, this indication is completed by 
issuing one or more FC-1 Data.|Indication 
primitives sufficient to represent the Unrec- 
ognized Ordered Set according to the 
defined data path width between the FC-1 
and FC-2 levels. 


2. Upon receipt of an incoming bit stream 
representing a recognized Ordered Set, the 
FC-1 Receiver indicates receipt of this 
Ordered Set by issuing an 
FC-1 Data_Indication with Type = 
Ordered Set and Code set to the appropriate 
value. 


3. Upon receipt of an incoming bit stream 
representing an Unrecognized Ordered Set, 
the FC-1 Receiver indicates receipt of this 
Ordered Set by issuing one or more 
FC-1 Data.Indication primitives sufficient to 
represent the Unrecognized Ordered Set 
according to the defined data path width 
between the FC-1 and FC-2 levels. 


4. Upon receipt of an incoming bit stream 
representing a data character that is not part 
of an Ordered Set, the FC-1 Receiver indi- 
cates receipt of this character by issuing an 
FC-1 Data.Indication with Type = 
Valid Data Byte and Code set to the appro- 
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priate value. Additional Valid Data_Byte 
entries are provided when the data path 
width between the FC-1 and FC-2 levels is 
Half Word or Word. 


5. Upon receipt of an incoming bit stream 
representing an invalid Transmission Word 
as specified by “Invalid Transmission Word 
rules,” the FC-1 Receiver indicates receipt of 
this word by issuing an FC-1_Data.Indication 
with Type indicating the appropriate condi- 
tion or conditions according to the rules 
described previously in this section. 


Decoded information is not passed to the FC-2 
level and FC-1 Data.Indication primitives are not 
issued by an FC-1 Receiver in the Loss-Of- 
Signal-Failure, Loss-Of-Synchronization-Failure, 
Loss-Of-Synchronization, or Reset states. 


J.5.2.4 Effect on receipt 


Receipt of an FC-1 Data.Indication primitive by 
an FC-2 level causes the FC-2 level to accept the 
received and decoded data indicated by the 
primitive from the FC-1 level. 


J.5.2.5 Additional comments 


This primitive is illustrated by the indication 
portion of figure 82 (a). 


J.6 FC-1_Receiver_Control 


J.6.1 FC-1_Receiver_Control.Request 


J.6.1.1 Function 


This primitive is used by the FC-2 level to 
request that the FC-1 Receiver be reset, enter 
the Offline state, or exit the Offline state. 


J.6.1.2 Semantics 
The  FC-1 Receiver _Control.Request = service 
primitive is defined as follows: 


FC-1_ Receiver_Control.Request(Control) 


Control The Receiver control request made by 
the FC-2 level. The allowable values 
of this parameter are Reset, 
Enter Offline, and Exit_Offline. The 
format of this parameter is not defined 


by the standard. 
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J.6.1.3 When generated 


An FC-2 level issues the 
FC-1 Receiver Control.Request primitive with 
Control = Reset to request that the FC-1 level 


Receiver be reset. This request may result from 
the FC-1 level Receiver entering a failure state, 
although the FC-2 level may issue the 
FC-1 Receiver Control.Request primitive with 
Control = Reset at any time. 


An FC-2 level issues the 
FC-1 Receiver Control.Request primitive with 
Control = Enter Offline to request that the FC-1 
level Receiver enter the Offline state. 


An FC-2 level issues the 
FC-1 Receiver _Control.Request primitive with 
Control = Exit _Offline to request that the FC-1 
level Receiver exit the Offline state. 


J.6.1.4 Effect on receipt 


Receipt of this primitive with Control = Reset 
causes the FC-1 level to initiate a reset condition 
in its Receiver. If the Receiver is not already in 
the reset state, the FC-1 level concurrently 
issues an FC-1 Receiver_State.Indication primi- 
tive to the FC-2 level with State = Reset. The 
FC-1 level is incapable of _ providing 
FC-1 Data.Indication primitives to the FC-2 level 
while a reset condition exists in its Receiver. 
When the Receiver reset condition is exited, the 
FC-1 level issues an 
FC-1 Receiver State.Indication primitive to the 
FC-2 level with State = Loss Of_Synchronization 
or Offline depending upon the state of the 
Receiver prior to the reset request. 


Receipt of this primitive with Control = 
Enter Offline causes the FC-1 level Receiver to 
enter the Offline state. The Receiver continues 
to provide FC-1_Data.Indication primitives to the 
FC-2 level. It also continues to process received 
Transmission Words under the rules of the Loss- 
of-Synchronization procedure specified in 
“Invalid Transmission Word rules,” but com- 
pletion of the procedure does not cause the 
Receiver to enter the Loss-Of-Synchronization 
state. 


Receipt of this. primitive with Control = 
Exit Offline causes the FC-1 level Receiver to 
enter the Synchronization Acquired state. 


J.6.1.5 Additional comments 


An FC-1 reset condition may result in a request 
to the FC-0 Receiver to attempt to reacquire bit 
synchronization. 


This primitive is illustrated by figure 82 (d). 


J./ FC-1_Transmitter_Control 


J.7.1 FC-1_Transmitter_Control.Request 


J.7.1.1 Function 


This primitive is used by the FC-2 level to 
request that the FC-1 Transmitter be enabled or 
disabled. 


J.7.1.2 Semantics 


The FC-1_ Transmitter Control.Request service 
primitive is defined as follows: 


FC-1 Transmitter_Control.Request(Control) 


Control The enable control request made by 
the FC-2 level. The allowable values 
of this parameter are Enable and 
Disable. The format of this parameter 


is not defined by the standard. 
J.7.1.3 When generated 


An FC-2 level issues the 


FC-1 Transmitter _Control.Request primitive with . 


Control = Enable to request that the FC-1 level 
Transmitter be enabled. 


An FC-2 level issues the 
FC-1_Transmitter_Control.Request primitive with 
Control = Disable to request that the FC-1 level 
Transmitter be disabled. 
J.7.1.4 Effect on receipt 
Receipt of this primitive with Control = Enable 


causes the FC-1 level to enable its Transmitter 
unless the Transmitter is in one of the following 
conditions: 


- The Transmitter is in the Failure state. 


- The Transmitter has been placed in the 
Not-Enabled state as a result of detection by 
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FC-O laser safety procedures of a laser 
safety condition (i.e., a condition which 
requires that the Transmitter cease trans- 
mission). 


If the Transmitter is not already enabled and it is 
not in one of the above conditions, the FC-1 level 
concurrently issues an 
FC-1 Transmitter State.Indication primitive to 
the FC-2 level with State = Working. Otherwise, 
receipt of this primitive with Control = Enable 
by a Transmitter does not result in a Transmitter 
state change. 


Receipt of this primitive with Control = Disable 
causes the FC-1 level to disable its Transmitter. 
If the Transmitter is in the Working state at the 
time of receipt, the FC-1 level concurrently 
issues an FC-1_ Transmitter _State.Indication 
primitive to the FC-2 level with State = 
Not Enabled. (The Transmitter is already disa- 
bled when in the Not-Enabled or Failure state: 
receipt of this primitive with Control = Disable 
by a Transmitter in one of these states does not 
result in a Transmitter state change.) 


J.7.1.5 Additional comments 


This primitive is illustrated by figure 82 (d). 


J.8 FC-1_Loopback_Control 


J.8.1 FC-1_Loopback_Control.Request 


J.8.1.1 Function 


This primitive is used by the FC-2 level to 
request that the FC-1 Loopback function be 
enabled or disabled. 


J.8.1.2 Semantics 


The FC-1_Loopback_Control.Request service 


primitive is defined as follows: 


FC-41_ Loopback_Control.Request(Control) 


Control The Loopback control request made by 
the FC-2 level. The allowable values 
of this parameter are Enable and 
Disable. The format of this parameter 


is not defined by the standard. 
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J.8.1.3 When generated 


An ~ FC-2 level issues the 
FC-1 Loopback _Control.Request primitive with 
Control = Enable to request that the FC-1 
Loopback function be enabled. 

An FC-2 level issues the 
FC-1_Loopback_Control.Request primitive with 
Control = Disable to request that the FC-1 
Loopback function be disabled. 

J.8.1.4 Effect on receipt 

Receipt of this primitive with Control = Enable 


causes the FC-1 level to enable its Loopback 
function unless the FC-1 Transmitter or Receiver 
is in a state not compatible with the Loopback 
function. When the Loopback function is 
enabled, information passed to the FC-1 level via 
FC-1 Data.Request primitives is shunted to the 
FC-1 Receiver and reflected in 
FC-1 Data.Indication primitives issued by the 
Receiver after Synchronization is reestablished 


(if necessary), overriding any information 
received by the FC-1 Receiver. 
Receipt of this primitive with Control = Disable 


causes the FC-1 level to disable its Loopback 
function. When the Loopback function is disa- 
bled, information passed to the FC-1 level via 
FC-1 Data.Request primitives is encoded and 
transmitted by the FC-1 Transmitter. Information 
received and decoded by the FC-1 Receiver is 
indicated to the FC-2 level by 
FC-1 Data.Indication primitives after Synchroni- 
zation is reestablished (if necessary). 


J.8.1.5 Additional comments 

The FC-1 Loopback function is disabled upon 
completion of Initialization of an FC-1 Trans- 
mitter and Receiver. 

Behavior of a Transmitter in the Working state is 
unpredictable when the FC-1 Loopback function 


is enabled. 


Loss of Synchronization may occur whenever the 
Loopback function is enabled or disabled. 


This primitive is illustrated by the request 
portion of figure 82 (c). 


J.8.2 FC-1_Loopback_Control.Confirm 
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J.8.2.1 Function 


This primitive is used by the FC-1 level to accept 
or reject the request that the FC-1 Loopback 
function be enabled or disabled. 


J.8.2.2 Semantics 


The FC-1_Loopback_Control.Confirm 
primitive is defined as follows: 


FC-1 Loopback_Control.Confirm(Status) 


Status The results of the 
FC-1_ Loopback_Control.Request _ primi- 
tive. The allowable values of this 
parameter are Accept and Reject. The 
format of this parameter is not defined 
by the standard. 


service 


J.8.2.3 When generated 


An FC-1 level issues _—stthe 
FC-1 Loopback_Control.Confirm primitive to an 
FC-2 level to indicate the acceptance or rejection 
of a previously issued 
FC-1_ Loopback_Control.Request primitive. 
Acceptance is indicated only when valid informa- 
tion is presented by the Receiver. via 
FC-1 Data.Indication primitives. 


J.8.2.4 Effect on receipt 


Receipt of the FC-1_Loopback_Control.Indication 
primitive with Status = Accept informs the FC-2 
level that the enabling or disabling of the FC-1 
Loopback function was successful or that the 
FC-1 Loopback function was already enabled or 
disabled. 


Receipt of the FC-1_Loopback_Control.Indication 
primitive with Status = Reject informs the FC-2 
level that the enabling of the FC-1 Loopback 
function was unsuccessful. A request to enable 
the FC-1 Loopback function is rejected whenever 
the FC-1 Receiver is not in the Synchronization- 
Acquired or Loss-Of-Synchronization state and 
the FC-1 Transmitter is not in the Working or 
Not-Enabled state. (A request to disable the 
FC-1 Loopback function is always accepted.) 


J.8.2.5 Additional comments 


This primitive is illustrated by the confirm 
portion of figure 82 (c). 
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Annex K. Communication models (informative) 


This annex provides communication model 


examples. 


K.1 Half-duplex communication 
model 


When one port of the channel only transmits 
Data frames and the other port only transmits 
Link level (Link_Control) responses, the channel 
is said to be performing half-duplex communi- 
cation. 


For example in figure 83, 


— N Port A(1) transmits a Data _ frame 
(command or data) on its outbound Fibre 
and N_ Port B(1) receives the Data frame on 
its inbound Fibre. 

In response, N Port B(1) transmits a 
Link_Control frame concurrently on its out- 
bound Fibre and N Port A(1) receives it on 
its inbound Fibre. 

Multiple Data frames from N_ Port A(1) and 
the respective Link Control 
N_ Port B(1) results in similar flow. 


Figure 83 depicts the FC-2 half-duplex communi- 
cation model with its logical structure and com- 
ponents. The model is composed of the 
following components: 


— Node A and B 
— N Ports A(1) and B(1) 
— Link_Control_ Facility (LCF) in each N_Port 


— Originator and Originator status in one 
N Port 
Node A | 
N Port A(1) 
S 1D = A(1) 
D_ID = B(1) 


ORIGINATOR 


STATUS 


ource Identifier 
estination Identifier 
ink Control Facility 


C7) nt ey 
“rE 

“on 
cr oN 


frames from 


Data frames from N Port A 


nses from N Port B 


Respo 
S_1D 
DID 


— Responder and Responder status in the 
other N_ Port 

The Originator is the logical function in an 

N Port A(1) which initiates an Exchange, 


whereas the Responder is the logical function in 
an WN Port which is the destination of the 
Exchange. Either N Port can be an Originator 
and the other N_ Port a Responder in figure 83 at 
any given time. The role of N Ports as Origi- 
nator and Responder shall not change during a 
given Exchange. 


K.2 Duplex communication model 


When both ports of a channel transmit Data 
frames and Link Control frames (responses to 
Data frames) in directions opposite to their 
respective Data frames, the channel is said to be 
performing duplex communication. 


For example in figure 84, 


— N Port A(‘1) transmits a Data frame on its 
outbound Fibre and N Port B(1) receives it 
on its inbound Fibre. 

Simultaneously N_ Port B(1) transmits its 
Data frame to N Port A(‘1) on its outbound 
Fibre and N Port A(1) receives it on its 
inbound Fibre. 

In response to the Data frame from N_Port 
A(1), N Port B(1) transmits a Link Control 
response on its outbound Fibre and N Port 
A(1) receives the response on its inbound 
Fibre. 

In response to the Data frame from N_Port 
B(1), N Port A(1) transmits a Link_Control 


Node B 
N Port B(1) 


RESPONDER 


STATUS 


Figure 83. FC-2 half-duplex communication model example 
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Node A 
N Port A(1) 


ORIGINATOR 


STATUS 


RESPONDER 


STATUS 


Node B 
N Port B(1) 


RESPONDER 


STATUS 


ORIGINATOR 
STATUS 


Figure 84, FC-2 duplex communication model example 


response on its outbound Fibre and N_Port 
B(1) receives the response on its inbound 
Fibre. 

— Multiple Data frames from N Port A(1), and 
N Port B(1) and the respective responses 
from N_ Port B(1), and N Port A(‘1) results in 
similar flow. 


Figure 84 depicts the FC-2 duplex communication 
model with its logical structure and components. 
The FC-2 duplex communication model is 
bidirectionally symmetrical and both communi- 
cating N_Ports have equivalent abilities. 


The FC-2 duplex communication model consists 
of an Originator and a Responder in each of the 
communicating N_ Ports. 


From the perspective of a given N Port, the Out- 
bound Fibre transmits a mixture of Data frames 
according to the activity generated by the N_Port 
and Link level responses to the Data frames 
received on the Inbound Fibre from the remote 
N_ Port. 


WN Port A(1) 


$ID = A(1) 


Data frames 


ORIGINATOR from N Port A(1) 


STATUS 


Legend: S$ ID = Source Identifier 
D_ID = Destination Identifier 
LCF = Link Control Facility 


(uni-directional) 
dual-simplex 
D_ID = B(1) Fabric 


K.3 Dual-simplex communication 
model 


When the channel transmits Data frames in one 
direction with the Link_Control frames arriving in 
the opposite direction, and limits the flow of Data 
frames and Link_Control frames at any given 
time to a single direction, the channel is said to 
be performing dual-simplex communication. 


For example in figure 85, 


— N Port A(‘1) transmits a Data frame on its 
outbound Fibre and N_ Port B(1) receives the 
Data frame on its inbound Fibre through the 
unidirectional Fabric. (simplex from A(‘1) to 
B(1)). 

— In response to the Data frame, N Port B(1) 
transmits a Link_Control response on its out- 
bound Fibre and, due to unidirectional limita- 
tion of the Fabric, N Port A(1) receives the 
response non-concurrently on its inbound 
Fibre. (simplex from B(1) to A(1)). 


N Port B(1) 


RESPONDER 


STATUS 


Figure 85. FC-2 dual-simplex communication model example 
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— Multiple Data frames from N Port A(1) and 
the respective responses from N Port B(1‘) 
results in similar flow. 


Figure 85 depicts the FC-2 dual-simplex commu- 
nication model with its logical structure and 
components. The FC-2 dual-simplex communi- 
cation model is functionally similar to the half- 
duplex model with the following difference. 
While the half-duplex communication model sup- 
ports simultaneous bidirectional flow of frames, 
the dual-simplex model allows only 
unidirectional flow at any given time. 
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Annex L. CRC Generation and Checking (informative) 


This appendix is an EXTRACT from Fiber Distributed Data Interface (FDDI) Media Access Control 
(MAC). (Document reference: ISO # 9314-2/x3.139-1987). FDDI’s Frame Check Sequence (FCS) method- 
ology, polynomials and equations are used by Cyclic Redundancy Check (CRC) in FC-2. The term FCS 
is unique to FDDI and not used by Fibre Channel. Note that CRC coverage of FC-2 fields is specified in 


FC-2 standard. 


4.3.6 Frame Check Sequence (FCS) 


This section specifies the generation and 
checking of the FCS field. This field is used to 
detect erroneous data bits within the frame as 
well as erroneous addition or deletion of bits to 
the frame. The fields covered by the FCS field 
include the FC, DA, SA, INFO, and FCS fields. 


4.3.6.1 Definitions 


F(x) - A degree k-1 polynomial which is used to 
represent the k bits of the frame covered by the 
FCS sequence (see section 4.2.2). For the pur- 
poses of the FCS, the coefficient of the highest 
order term shall be the first bit transmitted. 


L(x) - A degree 31 polynomial with all of the 
coefficients equal to one, ie., 
L(x) = X9*+ X94 K294 coe + K?2+ X + 1 


G(x) - The standard generator polynomial 
G(x) = X32 + X26 + X23 + X22 + Xe + X12 + 
Xt KIO KF+ K+ KO+ XA+ X7274+ KX + 1 


R(x) - The remainder polynomial which is of 
degree less than 32 
P(x) - The remainder polynomial on the receive 
checking side which is of degree less than 32 
FCS - The FCS polynomial which is of degree 
less than 32 
Q(x) - The greatest multiple of G(x) in 
[X°7F (x) + XkL(x)] 

Q*(x) - X°?Q(x) 
M(x) - The sequence which is transmitted 
M*(x) - The sequence which is received 
C(x) - A unique polynomial remainder produced 
by the receiver upon reception of an error free 
sequence. This polynomial has the value 

C(X) = X**L(X)/G(X) 


CX) = X24 KF KF K+ KA+ KBE K+ 


X44 X74 XM+ XMO+ KE XEF XSF XSF XI 
X+1 
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4.3.6.2 FCS Generation Equations 


The equations which are used to generate the 
FCS sequence from F(x) are as follows: 


FCS = L(X)+R(X) = R$(X) (1) 
where R§(X) is the one’s complement of R(X) 


[X°?F (x) + XKL(X)]/G(X) = Q(X) + R(X)/G(X) (2) 
M(x) = F(x) + FCS (3) 
NOTE: 
All arithmetic is modulo 2. 


In equation (1), note that adding L(x) (all ones) to 
R(x) simply produces the one’s complement of 
R(x); this equation is specifying that the R(x) is 
inverted before it is sent out. 


Equation (3) simply specifies that the FCS is 
appended to the end of F(x). 


4.3.6.3 FCS Checking 


The received sequence M*(x) may differ from the 
transmitted sequence M(x) if there are trans- 
mission errors. The process of checking the 
sequence for validity involves dividing the 
received sequence by G(x) and testing the 
remainder. Direct division, however, does not 
yield a unique remainder because of the possi- 
bility of leading zeros. Thus a term L(x) is pre- 
pended to M*(x) before it is divided. 
Mathematically, the received checking is shown 
in equation (4). 

X*70 M*(X) + XKL(X) ]/G(X) = Q*(X) + P(X)/G(X) (4) 


In the absence of errors, the unique remainder 
is the remainder of the division 
P(X)/G(X) = X*7L(X)/G(X) = C(X) (5) 
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Annex M. ACK_N Usage (Informative) 


Three examples are shown on the usage of 
ACK_N. Example 1 illustrates a case where all 
Data Frames are received in sequential order. 


SEQ CNT of Frame 
received 


ACK_N sent after receiving 
this frame 


Credit_CNT/SEQ CNT 
in ACK_N response 


| Examples 2 and 3 correspond to cases when the 
| Frames are received out of order. 


| ACK_N usage example 1: 


13 
+ 


F CTL(19)=1 


4/12 1/13 


Sequence SEQ CNT of 
Count Frames 
responded to 


1,2,3 and 4 
5,6,7 and 8 
9,10,11 and 12 


13 


Figure 86. ACK_N usage example 1 
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ACK_N usage example 2: 


SEQ CNT of Frames 
received 


ACK_N sent after receiving 
this frame 


Credit_CNT/SEQ CNT 
in ACK_N response 


12 


F CTL(19)=1 
r 


10 13 


C D 


4/12 1/13 


ACK_N content 


ACK_N Credit Count 
sent 
at 

A 4 

B 4 

C 4 

D 1 


Sequence SEQ CNT of 
Count Frames 
responded to 
4 1,2,3 and 4 
8 5,6,7 and 8 
12 9,10,11 and 12 
13 13 


| | gs Ne as 


Figure 87. ACK_N usage example 2 


ACK_N usage rules: 


1. 
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. ACK_N 


ACK_N always reports the number of ALL 
consecutive frames received within a 
window (in Credit_CNT field). 

always’ includes the maximum 
sequence count of the consecutive frames 
being reported (in SEQ CNT field). 


| 
| 
| 
| 
| 
| 
| 


Implementation Notes: 


1. 


2. 


3. 


Receiver tracks the max. SEQ CNT reported 
in the previous window. 

Receiver tracks the expected SEQ CNT 
which ts max. SEQ CNT reported plus 1. 
Receiver does not track more than n frames 
(n=4 in the examples 2 and 3) before 
sending an ACK_N. 
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ACK_N usage example 3: 


SEQ CNT of Frames 
received 


ACK_N sent after receiving 
this frame 


Credit CNT/SEQ CNT 
in ACK_N response 


ACK_N content 


ACK_N Credit Count Sequence SEQ CNT of 
sent Count Frames 
at responded to 
A 4 4 1,2,3 and 4 
B 3 7 5,6 and 7 
C 4 11 8,9,10 and 11 
D 2 13 12 and 13 


Figure 88. ACK_N usage example 3 
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Annex N. FC-2 Fabric Requirements (informative) 


N.1 N_Port requirements 


N.1.1 Receiver Control 


Receiver Control Flags (C) shall specify which 
protocols, or functions are supported by the 
N Port supplying the Service Parameters when 
acting as a receiver of device frames. Receiver 
Control Flags are specified by the FC-2 level. 


NOTE - FC-4 can further limit FC-2 capabilities. 


Receiver Ctl Flags (C) 


Echo Detect/Retry 
Alternating Type A/B 
Reserved 


Figure 89. Receiver control flags 


° Bit 42 - Echo Detect/Retry 


— 0 Echo Detect/Retry not supported by 
N_ Port 

— 1 Echo Detect/Retry supported by 
N_ Port 


Bit 42 specifies that the N Port supplying this 
information does or does not support the Echo 
Detect/Retry function within the N Port Link 
Control Facility. Echo Detect/Retry is activated if 
the Fabric (or other N_ Port, in point to point) 
requires this function. 


If Echo Detect/Retry is active, the N Port 
receiver monitors for frames which are the 
“Echo” of frames transmitted by the N Port by 
comparing the D_ID of the received frames with 
the address of the destination N_ Port, or by com- 
paring the S_ID of the received frames with the 
address of its N_ Port. 
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If a match is found, the frame has been success- 
fully transmitted to the destination N_ Port. If the 
“Echo” is not detected by the N Port receiver 
within a predetermined time (“retry” time), the 
frame has not been successfully transmitted and 
must be retransmitted. The “retry” attempts are 
repeated until the N_ Port successfully detects 
the “Echo” of the transmitted frame. 


Detection of an “Echo” is equivalent to receiving 
an R_RDY Link_Continue response. 


¢« Bit 41 - Alternating frame type required by 
Fabric 


— 0 Alternating frame type A/B not sup- 
ported by N_ Port 

— 1 Alternating frame type A/B supported 
by N_ Port 


Bit 41 specifies that the N_ Port supplying this 
information does or does not support Alternating 
frame type A/B function within the N_ Port Link 
Control Facility. This function is activated based 
on Fabric requirements specified in the Fabric 
Service Parameters. 


If the Alternating frame type A/B function is 
active, the N Port transmitter marks the frame 
with type A or B and then transmits. After the 
frame is successfully transmitted ("Echo 
detected”), the N Port transmitter changes the 
frame type before transmitting the next frame. 
Alternating frame type A/B is a method which 
attempts to provide “fairness” in a Broadcast 
type of Fabric. 


Bit 41 is ignored if Bit 42 is zero. NOTE - Frame 
type “A” for a Broadcast type of Fabric has been 
specified as a “normal” Idle word immediately 
preceding the SOF for a frame. Type ”B” would 
be a different encoding of an Idle word which 
precedes the SOF for a frame. These definitions 
need to be added to FC-1 and FC-2 for complete- 
ness. 


N.2 F_Port Requirements 


N.2.1 Receiver Control 


Receiver Control Flags (C) have the following 
designations for ALL classes: 


* Bit 42 - Echo Detect/Retry 


— 0 Echo Detect/Retry not required by 
Fabric 
— 1 Echo Detect/Retry required by Fabric 


¢ Bit 41 - Alternating frame type required by 
Fabric 


— OQ Alternating frame type A/B not 
required by Fabric 

— 1 Alternating frame type A/B required 
by Fabric 


Bit 41 specifies that the Fabric supplying this 
information does or does not require the use 
of the Alternating frame type A/B function 
within the N Port Link Control Facility 
attached directly to the Fabric. 


Bit 41 is ignored if Bit 42 is zero. 


N.3 Fabric Characteristics 


The following list of characteristics describes a 
fabric as viewed from an FC-2 Port. 


End to End communication 


FC-2 is based on endpoint to endpoint com- 
munication. An optional intervening fabric 
may be present within the physical config- 
uration. Features are provided within the 
FC-2 definition which allows several dif- 
ferent modes or classes of service between 
two endpoints which are interconnected by 
means of a fabric. 


FC-2 -- Reply to every Request/Command 


FC-2 protocol is based on receiving a Reply 
to every Request. Depending on the 
options chosen and the intervening fabric 
present, multiple replies may be received 
by an FC-2 Port for a single Request. 
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Sequential frame transmission 


Sequential transmission is required of the 
transmitting Port. The order of delivery is 
in the same sequence in some environ- 
ments and non-sequential in others. 


6 Idle sequences transmitted after a frame 


During frame transmission, 6 Idles are 
transmitted after one frame and before the 
start of the next frame. Up to 4 Idles may 
be removed by an intervening fabric for 
internal communication and clock skew 
management. However, 2 Idles are guar- 
anteed preceding the start of each frame at 
the receiving N_ Port. 


InBand Addressing 


Frames are routed by the fabric based on 
the destination address contained within 
the frame contents. 


Control Port 


A fabric shall have an addressable control 
Port in order to support various control 
functions. 


Service Classes 


Class 1 - Dedicated Connection 
Provides guaranteed service 
between two Ports as though 
the two Ports were physically 
interconnected on both transmit 
and receive fibres by a circuit. 


Class 2 - Multiplex 
Provides connectionless service 
with non-delivery notification 
between two Ports as though 
the two Ports were logically 
interconnected. Operates on a 
frame-switched basis. 


Class 3 - Datagram 
Provides connectionless service 
between two Ports as though 
the two Ports were _ logically 
interconnected. Operates on a 
frame-switched basis without 
non-delivery notification. 
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- Limited Frame size 


Frame Data Field size is always limited by 
the maximum size which the destination 
Port may receive. The frame establishing 
a Class 1 Connection, and all Class 2 and 3 
frames may also be limited by the 
maximum size supported by the inter- 
vening fabric buffers. 


Login 


Login with Fabric and the destination Port 
is always required. 


N.4 F_Port R_RDY processing 


** F_ Port receives frame from an attached N_ Port 


If (Frame_Header in Error) 
Then 
Begin 
F Port returns F_RJT (S_ID) 
F Port returns R_RDY (S_ID) 
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End 
Else 
Begin 
While (Elapsed time < Frame_timeout_period) 
Begin 
F Port attempts to send frame to N_Port (D_ID) 
if (F_Port sends frame) 
Then 
Begin 
F Port returns R_RDY (S_ID) 
Exit 
End 
End 
End While 
** Timeout reached without sending frame ** 
F Port returns F_BSY (S_ID) 
F Port returns R_RDY (S_ID) 
End 
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Annex O. Data transfer protocols and examples (informative) 


This annex summarizes Data transfer protocols 
with examples and provided as information. 


0.1 Introduction 


FC-2 provides Data transfer protocols to transfer 
data between N_ Ports or Nodes at two levels: 


1. Sequence level protocol 
2. Frame level protocol 


Sequence level 

Sequence level protocol is used by Originator 
and Responder pair of an Exchange. The Origi- 
nator issues a Request Sequence to the 
Responder who may issue a Reply Sequence in 
response. The Originator may in turn respond 
with another Reply Sequence and the communi- 
cation may continue until the end of the 
Exchange. The Originator or the Responder may 
issue multiple consecutive Sequences if it 
chooses to. A Sequence Initiative control bit in 
F CTL determines who (the Originator or the 
Responder) is allowed to transmit a Sequence at 
a given time. Control bits in F_CTL are used to 
indicate the first, intermediate, or the last 
Sequence in the Exchange. 


Frame level 

Frame level protocol is used by a Sequence Initi- 
ator (SI) and a Sequence Recipient (SR) pair. 
The Sequence Initiator issues one or more Data 
frames and the Sequence Recipient issues a 
Link_Control frame for each of these Data 
frames. Control bits in F_CTL are used to indi- 
cate the first, intermediate, or last frame in the 
Sequence. (see “24 Exchange, Sequence, and 
Sequence Count Management” for the definition 
of Exchange, Sequence, SI, and SR.) 


Users 

sequence level protocol is used by the ULP at 
its discretion and needs. Frame level protocol is 
used by FC-2 itself to communicate successful or 
unsuccessful frame delivery and frame level flow 
control. 


Applicability 
Sequence level protocol is Class independent. 
Frame level protocol is_ significantly Class 
dependent. 


Directions 

If an Exchange is made up of one or more 
Sequences flowing in a single direction (i.e., 
from Originator to Responder), the Exchange is 
said to be unidirectional. If an Exchange is 
made up of multiple Sequences flowing in both 
directions, the Exchange is bidirectional. 


0.2 Sequence level protocol 


Sequence level protocol is specified for 
Bidirectional Exchange. (Unidirectional 
Exchange is considered a special case of 
generic Bidirectional Exchange and not specified 
separately). 


The Originator starts the first Sequence of an 
Exchange. It may act as the Sequence Initiator 
and initiate one or more Sequence(s) before it 
passes the Sequence Initiative to the Responder. 
The Responder then may perform one or more 
Sequences and may pass the Sequence Initiative 
to the Originator. A Sequence is initiated by 
embedding SOFix (or SOFc’1) in a Data frame. 


The Exchange may be terminated either by the 
Originator or the Responder. One who termi- 
nates the Exchange shall own the Sequence Initi- 
ative and act as the Sequence Initiator for the 
Sequence in which it terminates the Exchange. 
The Exchange is terminated with the termination 
of the last Sequence. 


Figure 90 illustrates the Sequence level protocol 
with a request and a reply Sequence. 


Login and Estimate Credit procedures are exam- 
ples of Sequence level protocols. In Login pro- 
cedure, LOGI is a_e single frame _ request 
Sequence and the ACC to LOGI is a single frame 
reply Sequence. In Estimate Credit procedure, 
ESTS and ADVC are single frame _ request 
Sequences and ESTC is a request Sequence 
with three or more frames. The related ACCs 
are single frame reply sequences. Initiative to 
transmit is passed on completion of each 
request or reply Sequence. 
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0.2.1 Protocol description 


A Sequence flows from the Sequence Initiator to 
the Sequence Recipient. A Sequence is initiated 
by the Sequence Initiator with a SOFix (or SOFc‘1 
if establishing a Class 1 Connection as well) in 
the first Data frame of the Sequence. A 
Sequence is terminated by the Sequence Initi- 
ator by indicating the last Data frame in the 
F CTL. If ACK is used in the protocol, the 
Sequence Recipient embeds an EOFt (or EOFdt if 
removing the Connection as well). If ACK is 
suppressed in the protocol, the Sequence Initi- 
ator embeds an EOFt (or EOFdt) in the last Data 
frame. 


An Exchange is performed between an Origi- 
nator and a Responder. The Originator assigns 
an Exchange with an OX_ID = x and starts the 
Exchange by initiating the first Sequence with a 
SEQ ID = a. 


1. The Originator sends the first Data frame 
which 
A. may establish a Class 1 Connection, 

B. initiates an Exchange, and 
C. initiates the first Sequence of the 
Exchange. 

2. The Originator owns the Sequence Initiative 
when it initiates the Exchange. The Origi- 
nator acts as the Initiator and the Responder 
as the Recipient of this first Sequence. 

3. The Responder as the Sequence Recipient 
returns an RX_ID in its ACK within the first 
Sequence. 

4. On terminating the first Sequence, the Origi- 
nator may choose to _ initiate another 
Sequence or pass the Sequence Initiative to 
the Responder in the last Data frame of the 
Sequence. 

5. On receiving the Sequence Intiative from the 
Originator, the Responder may perform one 
or more Sequences as the Sequence Initi- 
ator. The Originator performs the function of 
the Sequence Recipient. 


6. As driven by the ULP, the Originator or the 


Responder terminates the Exchange when it 
is acting as the Sequence Initiator. The ter- 
mination of the Exchange is indicated by 
specifying the Sequence as_ the _ last 
Sequence and the last Data frame of the 
Exchange as the last frame in that Sequence. 

7. The termination of the last Sequence also 
marks the end of the Exchange. 
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Fabric N_Port 


SOFTx 
Request 
Sequence 
SEQ_ID a 
EO = 
SOF Ix | 
Reply 
| Sequence 
— SEQ_I b 
EOFt 


Figure 90. Sequence level protocol 


O.3 Frame level protocol 


Frame level protocol is specified for a Sequence 
flowing from the Originator to the Responder and 
is also applicable for a Sequence from the 
Responder to the Originator with appropriate 
value for Exchange Context and Sequence 
Context bits in F_CTL field. (Also see O4 for 
examples.) | 


Frame level protocol is Class dependent and is 
separately specified for each Class. Class 
dependent factors are: 


1. SOF delimiters 

2. Place of usage of EOFt/EOFdt 
3. ACK usage 

4. R_RDY usage 


0.3.1 Class 1 frame level protocol 


Class 1 frame level protocol employs 


1. Data frame 
2. ACK 


Class 1 frame level protocol is illustrated in 
figure 91. 


1. The Sequence is initiated by the Originator 
with a Data frame embedded with SOFc1 or 
SOFi1. SOFc1 is used to indicate a Connect 
request and the Sequence initiation. Within 
an established Connection SOFi1 indicates 
the Sequence initiation. 

2. Next Data frame is not sent until the Connect 
request is accepted by the destination. 

3. The Originator streams multiple Data frames 
and the Responder responds with ACK. 

— ACK returns following information con- 
tained in F_CTL of the Data frame to 
which it is responding unaltered. 

— First Sequence 

— Last Sequence 

— Last Data frame 

— Sequence transmit initiative 

— ACK toggles following information con- 
tained in F_CTL of the Data frame. 
— Exchange Context 
— Sequence Context 

F_CTL usage for the Sequence is described 

in table 69. 

4. SOFn1 is used to indicate the Sequence in 
progress. 

5. The end of Sequence is indicated to the 
sequence Recipient by the Last Data frame 
bit in F_CTL. The Last Data frame contains 
EOFt or EOFdt, if ACK is suppressed. The 
last ACK is embedded with EOFt or EOFdt if 
ACK is used. 

6. The end of Exchange is indicated to the 
Sequence Recipient by the Last Sequence 
and the Last Data frame bits in F_CTL. The 
Last Sequence and the EOFt or EOFdt indi- 
cate to either N_Port the end of Exchange. 
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N_Port Fabric N_Port 


SI SR 
SEQ_ID 


Data frame 


__ Data frame 


~~ we 


Figure 91. Class 1 Frame level protocol 
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0.3.2 Class 2 frame level protocol 


Class 2 frame level protocol employs 


1. Data frame 

2. ACK 

3. R_RDY 

Class 2 frame level protocol is illustrated in 
figure 92. 

1. The Sequence is initiated by the Originator 
with a Data frame embedded with SOFi2. 

2. The F_Port if present responds with an 
R_RDY and forwards the Data frame to the 
destination. 

3. The destination responds with an R_RDY, in 
addition to ACK. 

4. The F_Port and the N Port respond with 
R_RDY each on receipt of ACK. 

5. The Originator streams multiple Data frames 
and the Responder responds with ACK. 

6. For each of these frames received except 
R_RDY, each N Port or F Port, returns a 
R_RDY. 

— ACK returns some information contained 
in F_CTL of the Data frame to which it is 
responding unaltered. 

— First Sequence 

— Last Sequence 

— Last Data frame 

— Sequence transmit initiative 

— ACK toggles some information contained 
in F_CTL of the Data frame. 
— Exchange Context 
— Sequence Context 

F CTL usage for the Sequence is described 

in table 69. 

7. SOFn1 is used to indicate the Sequence in 
progress. 

8. The end of Sequence is indicated by the 
Sequence Initiator by the Last Data frame bit 
in F_CTL. However, the Sequence ends in 
the perspective of Sequence Recipient, only 
when all Data frames are received or 
accounted for. 

9. The Sequence Initiator places in the final 
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frame, EOFt or EOFdt only after all other 
frames are acknowledged, if ACK is sup- 
pressed. If ACK is used, the Sequence 
Recipient transmits EOFt or EOFdt only in the 
final ACK after all Data frames are received 
or accounted for. 


Fabrie 


Data frame 


Dota frame 


Figure 92. Class 2 Frame level protocol 
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0.3.3 Class 3 frame level protocol 


Fabric 

Class 3 frame level protocol employs 

1. Data frame 

2. R_RDY 

Class 3 frame level protocol is illustrated in 
figure 93. 

1. The Sequence is initiated by the Originator 
with a Data frame embedded with SOFi3. 

2. The F_Port if present responds with an Data frame 
R_RDY and forwards the Data frame to the OTS ata: 
destination. 

3. The destination responds with an R_RDY. 

4. The F_Port and the N Port respond with 
R_RDY each. Data frame 

5. The Originator streams multiple Data frames. ata ei 
For each of these frames received except 
R_RDY, each N Port or F_Port, returns a 
R_RDY. F_CTL usage for the Sequence is 
described in table 70. 

6. SOFn3 is used to indicate the Sequence in : 
progress. 

7. The end of Sequence is indicated to the 
sequence Recipient by the Last Data frame 
bit in F_CTL and EOFt. Data frame 


~~ ew 


Figure 93. Class 3 Frame level protocol 
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Table 69. F_CTL for Class 1 or Class 2 frame level protocol | 


First Last Last Data Sequence 
Sequence of Sequence frame of transmit 
Exchange of Exchange Sequence initiative 


romps | 29 | ef at et 


0 
First Data 0 0 1 0 9 (hold 
frame (ORG) (SI) (First Sequence) Sequence 
Initiative) 


1 
(transfer 


P_RDY or 1 1 { 0 
ACK (RSP) (SR) (First Sequence) 


Exchange Sequence 


Description 


Context Context 


Sequence 
Initiative) 


Interme- 
diate Data 
frame(s) 


Last Data 
frame 
P_RDY or 
ACK 


Table 70. F_CTL for Class 3 Frame level protocol 


First Last Last Data Sequence 
Sequence of Sequence frame of transmit 
Exchange of Exchange Sequence initiative 


0 
First Data 0 0 1 0 (hold 
frame (ORG) (SI) (First Sequence) Sequence 
Initiative) 
Interme- 
diate Data 
frame 
Last Data 
frame 


Exchange Sequence 


Description Context Context 
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0.4 Sequence level protocol example 


Sequence level protocol is illustrated with a 
three Sequence Exchange in figure 90. The first 
sequence is a “read” request. The second 
Sequence transfers the “data”. The third 
Sequence transfers “ending status” and ends the 
Exchange. 


Frames 1,2, and 3 represent the first Sequence 
of an Exchange. In this example a Command 
Request for a Read operation is sent as a 
request Sequence. Note that Sequence Initiative 
is transferred to the Sequence Recipient. 


Frames 4,5 and 6 represent the first, interme- 
diate and last frames of the data transferred in 
response to the Read request. Note that the 
sequence Initiative is retained in order to start a 
Sequence with ending status. 


Frames 7,8 and 9 represent the ending status for 
the preceding data transfer and end _ the 
Exchange. Depending on the Upper Level Pro- 
tocol, the Responder may not be allowed to end 
the Exchange, but transfer the Sequence initi- 
ative to the Originator to complete the Exchange. 


F_CTL usage 


Use of F_CTL bits for these example Sequences 
are shown in table 71. 
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N_Port Fabrie N_Port 
ORG RSP 
OX_ID 25 RX_ID 36 

SI 
SEQ_ID2 Data frame 1 
cies SOF Ix 
2 
> 
EOFt ——3 
S| 
Data frame SEQ_ID 4 
SOFlx : 
5 
Pe) 
6 
na EOFt 
| S| 
Data frame SEQ_ID 5 
SOF Ix 7 
<@ 
‘a 
—_ ce 
9 EOFt 


Figure 94. Sequence level protocol example 
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Table 71. F_CTL for Bidirectional Exchange example 


First Last Last Sequence 
Exchange | Sequence | Sequence | Sequence Data transmit 


Description 


Context Context of of frame of initi- 
Exchange | Exchange | Sequence ative 
1. First Data frame (SOFix) 
of the Exchange and , 
(a Read Request Sequence) 
2. Intermediate Data frame 
of first Sequence 
4. First Data frame (SOFix) 
of intermediate Sequence 
5. Intermediate Data frame 
of intermediate Sequence 
6. Last Data frame , 
of intermediate Sequence 
of the Last Sequence 
(Reply Status Sequence) 
9. Last Data frame 
of the Last Sequence 


F_CTL Bits a ee ee ee 
of the first Sequence 
3. Last Data frame 
of first Sequence 
(Reply Sequence) 
Soe pede fe fe 
8. Intermediate Data frame | | 
of the Last Sequence 


and of the Exchange 
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0.5 Class 1 Frame level protocol 
example 


N_ Port Login is used as an example to illustrate 
Class 1 frame flow. 


N_Port Fabric N_Port 


ORG RSP 
OX_ID 4 RX_ID 5 


Sl 
SEQ_ID 2 


oo” 


“PRDY / ACK 


Figure 95. Class 1 Frame level protocol - Login 
example 
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0.6 Class 2 Frame level protocol 
example 


N Port Login is used to illustrate Class 2 frame 
flow. 


N_Port 
Fabrle N_Port 
OX_ID 4 RX_ID 5 
S| 
SEQ_ID 2 
_ LOGIN 
oT. SOFI2 
eta EOFt 
PROY / ACK 
SI 
SEQ_ID 1 
ACCEPT 
SOFI2 eeen 
EOFt 7 
PRDY / ACK 


Figure 96. Class 2 frame level protocol for Login 
example 


0.7 Class 3 Frame level protocol 
example 


N Port Login is used to illustrate Class 3 frame 
flow. 
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Fabric 


ACCEPT 


Figure 97. Class 3 frame level protocol for Login 
example 
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Annex P. Connection Management applications (informative) 


P.1.1 Case 1 


Table 72 shows a Case where N Port (A) trans- 
mits its last Sequence without N_ Port (B) trans- 
mitting any Sequences. 


Table 72. Case 1 


N_Port Actions 
A = this N_Port 
= other connected N_Port 


A transmitting Sequences 


A transmits last Data frame of 
last Sequence 


A receives the ACK_1 or ACK_N to 
the last Data frame with EOFat 
-- Connection Removed 


P.1.2 Case 2 


Table 73 shows a Case where N _ Port (A) com- 
pletes its last Sequence before N_Port (B). 


Table 73. Case 2 


N_Port Actions 
A = this N_Port 
= other connected N_Port 


Lod Both A and B transmitting Sequences ) 
A transmits last Data frame of 
last Sequence 
B completes Sequences in progress, 
A responds with Link_Continues 


A receives the last Data frame 

of last Sequence from B 
A transmits EOFdt on ACK_1/ACK_N 
-- Connection Removed 
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P.1.3 Case 3 


Table 74 shows a Case where N_ Port (B) trans- 
mits its last Sequence before N_ Port (A). 


Table 74. Case 3 


N_Port Actions 
A = this N_Port 
(A) (A) = other connected N_Port 


Both A and B transmitting Sequences 
A receives last Data frame of 
last Sequence from B 


Po)06UdF OY A completes Sequences in progress | 


A transmits last Data frame of | 
last Sequence 

A receives EOFat on ACK_1/ACK_N 

-- Connection Removed 


P.1.4 Case 4 


Table 75 shows a Case where N Port (A) trans- 
mits its connect-request with E_C set to one. 


Table 75. Case 4 | 


N_Port Actions 
A = this N_Port 
(A) (A) B = other connected N_Port 


A transmits connect-request with E_C set to one 


A receives the ACK_1 or ACK_N with EOFat 
-- Connection Removed | 
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P.1.5 Case 5 


Table 76 shows a Case where N Port (A) trans- 
mits its last Data frame of its last Sequence 
simultaneously with receiving the last Data 
frame of N_Port (B)’s last Sequence. 


Table 76. Case 5 


_Port Actions 
this N_Port 
other connected N_Port 


Both A and B transmitting Sequences 
(A is Connection Initiator) 
A transmits last Data frame of 

last Sequence 


A waits for its Link_Continue response 

A receives its ACK_1/ACK_N from B | 
with EOFn1 3 

A transmits ACK_1/ACK_N with EOFat 

-- Connection Removed 


A receives Data frame from B before receiving 
Link_Continue for its last Data frame with E_C = 1 
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P.2 Ending Sequence and 
Connection 


Table 77 shows an example of F_CTL Bit settings 
for key Data frames within an example 
Exchange. 


The first Sequence is a “read” request. The 
second Sequence transfers the “data”. The third 


Sequence transfers “ending status” and ends the 
Exchange and terminates a Class 1 Dedicated 
Connection. 


Table 77. F_CTL for example Exchange 


Description 


NO 
Ww 


1.First Data frame 
of Exchange (SOFix) 


- a Read request(xmit) 


2.Intermediate 
Data frame 
of first Sequence (xmit) 


3.Last Data frame 
of first Sequence (xmit) 
Se ee ee ee 


4.First Data frame 
of reply “data’ 
Sequence (SOFix)(recv) 


5.Last Data frame 
of reply data Sequence 
(recv) 


6.First Data frame 
of reply Status 
Sequence (SOFix)(recv) 


7.Last Data frame 
of Exchange (recv) 


8.Last ACK_1 
of Exchange (xmit) 


with EOFat 


Frames 1,2, and 3 represent the first Sequence 
of an Exchange. In this example a Command 
Request for a Read operation is sent as a 
request Sequence. Note that Sequence Initiative 
is transferred to the Sequence Recipient. 


Frames 4 and 5 represent the first and last 


frames of the data transfer associated with the 
Read operation. Note that the Sequence Initi- 
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Seq 
xmit 
initiative 


ative is retained in order to start a Sequence 
with ending status. 


Frames 6 and 7 represent the ending status for 
the preceding data transfer and ends the 
Exchange. Frame 7 ends the Sequence, ends 
the Exchange, and requests termination of the 
Connection. The ACK_1 response to frame 7 
(frame 8) removes the Dedicated Connection 
with EOFat. (This example assumes the other 
N_ Port never transmitted a Sequence and, there- 
fore, never transmitted E_C set to one. 


P.3 N_ Port States 


With respect to Class 1 Service, the establish- 
ment and removal of Class 1 connections can be 
viewed as a number of separate and distinct 
states within an N_ Port 


Inactive (IN) 


An N Port is in the Inactive state 
when it is not in any other state. In 
the Inactive state, an N_ Port is avail- 
able to initiate a Dedicated Con- 
nection request or to respond to a 
request to establish a Dedicated Con- 
nection. 


Busy (BS) 


When an N Port is in the Busy state 
because of internal reasons, the 
N_ Port is unable to initiate or respond 
to a request to establish a Dedicated 
Connection. The Busy state Is a 
normal, temporary condition. 


Connect_Try (CT) 


This state within the N Port results 
when this N Port has initiated a 
connect-request (SOFc1) and the des- 
tination N Port has_ not _ yet 
responded. 


This state within the N Port also 
results when another N_ Port has initi- 
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ated a connect-request (SOFc1) which 
this N_ Port has received but not yet 
responded to. 


Connected (CN) 


This state results after this N Port (A) 
has transmitted a connect-request 
(SOFc1) to a destination N Port (B) 
and this N Port (A) has received a 
response frame from the destination 
N Port (B) started by SOFn1 or by 
SOFi1 (ie. N_ Port (A) is the source of 
the connect-request). A Dedicated 
Connection is now established. 


This state also results after this 
N Port (A) has received a connect- 
request (SOFc1) from another N_ Port 
(B) and this N Port (A) has trans- 
mitted a response frame started by 
SOFn1 (ie. N Port (A) is the destina- 
tion of the connect-request). A Dedi- 
cated Connection is now established. 


Disconnect_Pending (DP) 


The state results after this N_ Port has 
transmitted a frame with the 
End Connection Bit in F_CTL set to 
one. | 
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P.4 State Diagram 
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INACTIVE 


BUSY 


. transmit SOFc1 


Source 


. receive BSY or RJT with EOFat 


. receive SOFc1 - Dedicated Connection as 


Destination 


5 
4——————->| CONNECT. 
TRY ——— 
ns 
vv 
DISC_ 
PENDING|<—6 


. receive SOFn1 - Dedicated Connection as 


CONNECTED 


. transmit SOFn1 - response to SOFc1 from 


another N_ Port 


. transmit or receive frame with E_C set to 


one 


. transmit or receive EOFat 


. Internal Busy condition cleared 


index 
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